Malware

Forged memory fools antimalware: A new development in rootkits

Malware developers are deploying a new stealth technology. Michael Kassner interviews an expert who explains how some rootkits forge memory to outwit antimalware programs.

Rachit Mathur, Senior Antivirus Researcher for McAfee, was investigating what he assumed to be a variant of the TDL3 rootkit, known for hiding the infamous Google Redirect Virus. But, it was acting weird. Mr. Mathur explains:

It was very interesting to see some of the anti-rootkit tools not showing the dispatch table hooks that are usually pretty straightforward to identify. Also, this malware would not allow an external debugger (WinDbg) to break, which was annoying.

Mr. Mathur adds:

The reason for hooks not being reported was that the memory being read by the tools was not the actual memory!

Obviously, the motivation for malware authors to use such techniques is to prevent tools from showing their hooks so that administrators are not alarmed of suspicious activity.

How is that possible?

I immediately wondered, "How in the world did he figure that out?"

His background offers a clue. Mr. Mathur has a M.S. in computer science specializing in reverse engineering, program transformation, and metamorphic malware. And, he has published in numerous venues: Journal in Computer Virology, Virus Bulletin, International Conference on Information Warfare, and IEEE International Workshop on Source Code Analysis and Manipulation.

That also explains the detail presented in his McAfee Labs blog post: Memory Forging Attempt by a Rookit. I tried to understand. But, pointers, register settings, and debug routines got the best of me. Knowing this is too important to screw up, I enlisted the help of Mr. Joris Evers of McAfee Corporate PR and Mr. Ian Bain of H3O Communications to connect with Mr. Mathur.

Kassner: I confess. I do not grasp how memory forging works. In lay terms, could you please describe what's going on? Mathur: Let me provide some background. Rootkits typically modify certain areas in the memory of the running operating system (OS) to hijack execution control from the OS. Doing so forces the OS to present inaccurate results to detection software (anti-virus, anti-rootkit).

For example rootkits may hide files, registries, processes, etc., from detection software. So rootkits typically modify memory. And anti-rootkit tools inspect memory areas to identify such suspicious modifications and alarm users.

This particular rootkit also modifies a memory location (installs a hook) to prevent proper disk access by detection software. Let us say that location is X. It is noteworthy that this location X is well known for being modified by other rootkit families, and is not unique to this particular rootkit.

Now since the content at location X is known to be altered by rootkits in general, most anti-rootkit tools will inspect the content at memory location X to see if it has been modified.

Kassner: Sorry to interrupt, but I wanted to mention, this is where the rootkit gets sneaky. Mathur continues: In the case of this particular rootkit, the original (what's expected) content at location X is moved by the rootkit to a different location, Y. When an anti-rootkit tool tries to read the contents at location X, it is served contents from location Y. So, the anti-rootkit tool thinking everything is as it should be, does not warn the user of suspicious activity. Kassner: You mention locations X and Y. My immediate thought is: If antimalware checks location X, why place the malware information at that location? Mathur: Malware changes the content at location X because the operating system (OS) uses location X to call OS-specific code that handles access to disk. That way during disk access, the malware gets to decide if it wants to allow access to the files being requested by a program or the planted malcode. This is called a dispatch table hook or IRP hook. Kassner: Are you saying the malware is intelligent enough to know what program wants access to location X? Wow. I'm afraid to ask, but how does it do that? Mathur: The malware definitely needs to determine where the read query is coming from. Only then will it be able to make sure the OS reads the 'actual' contents at location X and ends up calling the malware code that inspects disk access. Whereas other programs (including anti-virus) read the 'fake' contents at location Y.

When a read access occurs at location X, due to the CPU hardware breakpoint being set, an exception is triggered. Since the malware also modifies an OS variable named KiDebugRoutine, the malware code gets control when such an exception is triggered.

Here the malware is able to ascertain the address of the instruction that is trying to read. The malware compares this address with a pre-defined list of addresses that the malware wants to allow access. These addresses either belong to the OS or to the malware itself.

If the address of the instruction performing the read matches one of the pre-defined ones then the malware does not forge memory. The code that does this can be seen on the blog in figure "KiDebugRoutine Handler: Snippet 3".

The following code compares against one such pre-defined address. If it matches then the exception is set as handled without forging the memory and the execution will resume to read the 'actual' contents:

cmp   eax, dword_41D810 ; compare EIP with pre-defined locations that are allowed to read correct memory

jz   loc_403BC5  ; set as handled and return

Kassner: Does this rootkit have a name? Mathur: McAfee detects it as TDSS.e!rootkit. Kassner: I'm really curious. How did you determine the rootkit was forging memory? Mathur: When analyzing this malware sample, some common tools did not report any suspicious rootkit-like activity. But, further analysis and debugging revealed there was indeed a hook. And, it was located at a memory location where those tools commonly inspect. Yet, they did not report finding a hook. This was bizarre and really caught my attention.

Fortunately, the malware's implementation is not perfect. That became apparent during my investigation. I observed that two different methods used to inspect the same memory area were returning different results. That was an unexpected clue.

Because we knew what we were looking for, it did not take long to realize that a hardware breakpoint (DR0 register) was set to location X and malware was trying to protect it. The rest was typical reverse engineering to figure out the details of its workings.

Kassner: Is this something we can expect more of? Or since you now know it is actively "in the wild", will malware developers move onto something different? Mathur: That's a good question. Now that the technique is known to be used out there, we will certainly see anti-rootkit tools adding features to cope with this, like watching for hardware breakpoints before accessing memory or looking for KiDebugRoutine hooks, etc.

One would not expect this technique to become popular across many different malware families due to the need for setting a hardware breakpoint. Because, it is easy to avoid falling into this trap once you know about it.

But, updating anti-rootkit features take time. So, we may see this being used by a few versions of malware. And, we expect to see variations in the implementation details.

It is interesting to note that sophisticated malware will likely adopt this first. While less-intricate malware incorporate it, more slowly, extending its use. What actually happens is anybody's guess, but these seem reasonable possibilities.

Kassner: As users, how do we avoid memory-forging malware? Mathur: From a user perspective, normal precautions like safe browsing and keeping software up to date will help. Also, detection software may need updating to cope with this. So users should get the latest version and always have current anti-virus definitions. Kassner: In the blog, you alluded to the fact that this was a known technique, but not actively used. Are any other new and sneaky techniques looming on the horizon? Mathur: This technique has been mentioned in the past, but there were no reports of it being used by malware, until now. Unfortunately, we have not seen the last of such techniques. We expect malware authors to continue adopting and innovating better ways to hide.

This is something we intend to discuss at this year's Virus Bulletin Conference, along with our predictions of what might be coming.

Final thoughts

The cat and mouse game continues. Thanks to people like Mr. Mathur, we have a fighting chance.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

90 comments
gibsonkapokosa
gibsonkapokosa

I find this article particulary useful in educating users on the danger and difficulties in detecting and removing malware. Some users I have encountered erroneously believe that as long as they have up to date anti-malware software they would stay free from malware. they also believe that detecting and removing malware is a straight forward job, which clearly isn't

SkyNET32
SkyNET32

One on my mac right? Or would there have to be some pop-up asking me for my password for something that I didn't install intentionally, right? ;) @jacqui, That rootkithunter isn't compatible with mac past 10.3.8. @michaelKassner, That was a great article/interview with Charlie Miller. I'm going to send it to a "mac fanboy" friend of mine and say "ah ha!" :D

SkyNET32
SkyNET32

@michael Kassner, thanks for the links on Mr. Miller. I will certainly read up on it. @Jacqui, thank you, I believe then, by your first sentence that that is no longer the case? Rootkits for Unix systems may no longer need your password? @JCitizen. HAHA! I have to agree also, but being a Librarian, I like to stay on top of these topics and see what everyone else is saying across the Internet, even if yes, sometimes they do make my gums ache. ;)

SkyNET32
SkyNET32

He had about a working exploit for the Mac. People bashed him in the comments section and the thread (as usual) turned into a Mac "fanboi" vs MS argument. I wanted to ask a question but figured I'd get drowned out by all the bickering; There is this notion of the 'privilege escalation' syndrome, where folks say, the only way (on a mac only?) malware would "burn you" is if the user allowed it to (you have to provide your password - is that correct?) So, my question is, isn't there malware (for the Mac and Windows for that matter) that can override the OS's built-in "please provide your password or I won't let you execute" security feature? Discussions about "the problem lies between the keyboard and your chair sir" aside, can malware in fact, be sneaky and smart enough to not need a user's password to infect a machine, Mac or otherwise? I thought I'd ask here to see if it is in fact true or not. It seems to be a mantra among Mac users that "there is no malware in the wild for the mac". I have a mac myself and I Bootcamp it with Windows 7 (I'm so proud of myself! :D) and I like them both so, I'm not partial to either one. Can anyone help with this question? Thanks, Philip P.S. Forgive me if I sound pretty dumb, its been a while since I've listened to a Steve Gibson podcast. XD P.P.S Oops, I forgot to supply the Bott article if anyone was wondering http://www.zdnet.com/blog/bott/coming-soon-to-a-mac-near-you-serious-malware/3212?tag=mantle_skin;content

pgit
pgit

I've always wondered why there can't be some form of randomization of memory locations that would thwart any attempt at an exploit because the malware writer would have no way of targeting a given function, seeing as it'll be a different address at every boot. Sort of like a benign root kit. I know windows does a modicum of randomization of memory allocation, but that's way up the food chain at the application level. Maybe there's just too much overhead for such a thing to work. But maybe a modular approach could work, have the three basic files that load the OS bump their base up or down a block or two and translate all calls, the math should be simple, but I bet the hardware simply won't allow enough randomization. I know nothing about low level coding, I suppose I shouldn't speculate about such things. I've also often wondered if there isn't a physical, non code-based way to detect a root kit, say an anomaly in the radiation field emitted by the processor. Have a micron sized starship Enterprise hovering over the CPU checking it's surface for anomalies with the sensors... :)

OldGuru
OldGuru

Pre-boot scans, provided the AV has the rootkit's signature, are not fooled by this exploit simply because scan is performed before operating system is loaded. I know Avast provides such scan. But there is another thought that's bugging me; even if AVs have the right signatures, still rootkits can get around pre-boot scans by encrypting themselves and storing the encrypted copy with the encryption key on the disk in a, say, jpg file. At boot time, instead of the rootkit, a simple "loader" can be loaded to load and decrypt the rootkit, re-encrypt it with another random key, and save it to the disk. Even a simple scrambling technique, such as XORing the code with a randomly generated pattern, can ensure the rootkit is not detected in a pre-boot scan. The loader itself is not detected because it is not a malware itself and AV's don't look for it. Even if they do, it's much easier to create different variants of a simple loader than the rootkit itself.

Michael Kassner
Michael Kassner

You are certainly right and the bad guys do not want it to be easy.

SkyNET32
SkyNET32

I've done some research myself on antimalware programs, maybe 9 months worth? I've looked at various independent places that rate AV programs, gone over a lot of newsgroups, blogs, websites (av-comparatives.org for example), pcmag, all that stuff and I've always seen the same pattern emerge; AV suites have their strengths and weaknesses in different areas of their programs: one's firewall is better than anothers etc, one fights spam better than another. With that said, according to what they are reporting, AV programs have a bad reputation when it comes to detection and removal. They detect only up to say 94% of malware thrown at it; of that per cent, up to 89% or a bit more is actually removed. Do you understand? Even the malware that has a written definition for it DOES NOT ALWAYS REMOVE IT. Well, that bothers me. AV programs work in two ways: by definitions in its database, or some form of behavioral monitoring; which can be spot on, or way off. I have to take my hat off to some of these companies though, since this cat and mouse game takes a lot to ask from these programs. Still, when you have, in the case of malware that has submitted definitions intended for its removal - it should be detected AND removed 100% of the time, not between 94-96%! I can understand in the case of zero-day exploits, or behaviorally, its not guaranteed, but for malware where companies have actually "tested" or updated their software for a particular piece of malware, and it doesn't always get removed? I find that unacceptable. I wanted to know WHY. The only answer I can glean from my research, and talking or emailing individuals, was that since most of the time we're talking the Windows platform, the same principle or syndrome also applies in the case of installing or removing a program: How many times does Windows leave pieces of software behind, in its registry, or leaves folders behind (why?) - and that's when you deliberately installed something and want to remove it, now try it with malware that doesn't want to leave. No wonder there are programs like Revo Uninstaller. I feel it is a combination of poorly written code (on everyone's front, from Windows to applications like AV, and even the malware writers, but hey, that's their intent, right?) and something inherent in the windows NTFS file system, and how it handles blocks of data on drives. If legitimate programs don't get removed cleanly, fully, and easily, what makes us think an AV's software will be able to do it in the case of malware? I think Microsoft needs to restructure their file system, get rid of the ugly Registry maybe? We need companies to write tighter code, audit their code more (with security in mind) and a company's business model needs to change to accomodate their coders so they aren't pushed into releasing poor code before its been checked. Too many times management in companies - big companies ignore their engineers in favor of deadlines and bottom lines, and worry about the fallout later. That's no good. Maybe if government stepped in and made these companies (especially the AV companies) be held responsible for their products - no more of this attitude of "well its not our fault your system or network got hosed because of OUR shoddy code", they would listen. *sigh* Any thoughts? Sorry for the long post... :( Philip

Jaqui
Jaqui

hmm, then Apple is working to change things so that anti malware tools won't work on their flagship pc platform.

Michael Kassner
Michael Kassner

Solid with anything Apple and being ex-NSA gives him plenty of street-cred. He is why I use Chrome. Says it is the least hackable web browser, currently.

seanferd
seanferd

It does seem to have less vulnerabilities and better privilege separation than, e.g., Windows. Ed Bott does tend to sift the comments and respond to serious posts. I gave up on the comments at ZDNet long ago, but Ed has not, last I knew. Ask your question while the article is still current. edit: It seems to be a mantra among Mac users that "there is no malware in the wild for the mac". http://www.google.com/search?ie=UTF-8&oe=utf-8&q=OS+X+malware

Jaqui
Jaqui

a rootkit needs to be installed, but thier original purpose was to get that password so they could then take control and do whatever to the system the Unix and Unix-like operating systems [ MacOS is a Unix ] are specially vulnerable since rootkit design is targeted at the Unix / Unix-like method of privilege escalation. currently rkhunter is the promoted tool to find them, but it should be installed before the system is taken online at all after a clean os install. http://www.rootkit.nl/projects/rootkit_hunter.html

Michael Kassner
Michael Kassner

First off, you do not sound dumb. That is reserved for me. I have read Ed???s article. And intend to watch with interest, how it will play out. I might suggest paying attention to anything Charlie Miller says. He is the one, when it comes to Apple and security. He wins almost every Pwn 2 Own and focuses on Apple. Here is a link to an article about him: http://www.forbes.com/forbes/2010/0412/technology-apple-hackers-charlie-miller.html I have written about Windows 7 and how privilege escalation is now possible due to the change in how the UAC works: http://www.techrepublic.com/blog/security/microsofts-uac-a-change-in-philosophy-from-vista-to-windows-7/2619 Both Mark Russinovich and Jim Allchin agree that the move was for convenience and not security. Thus, leaving the door open for bad guys to manipulate the UAC. Finally, I am trying to verify that operating system preference is not an issue with this methodology. It appears rootkits are OS-agnostic.

Michael Kassner
Michael Kassner

It was something I noticed right away. We got into trouble with DNS, as it was not randomized sufficiently. Now we are there again, it seems.

MarkGyver
MarkGyver

All OS files should be digitally signed with strong cryptography (e.g. 2048-bit or longer RSA). Then all the scanner has to do is check that all OS and boot files are properly signed. If they are, there's no rootkit; if they aren't, it's time to replace them with backup copies. For OS files that cannot be digitally signed (mostly configuration files), the scanner can still compare them against the defaults and report the differences. Once the user confirms those versions of the files are okay, the scanner compiles a list of checksums for the confirmed versions and digitally signs the checksum list before saving it in a file on the drive. When dealing with Windows, the scanner should also generate separate checksums for each section of the registry, because that file contains a mess of configuration for just about everything. Since the rootkit is able to change any file on the computer it's on, the backups should be stored on CD/DVD and the scanner should be a live CD (user-made with its own 4096-bit RSA key for digitally signing the checksum list files it makes). With both scanner and backups on read-only discs, I think the only level left for rootkits to infect without being detected would be at the motherboard, which I'm clueless about protecting.

Michael Kassner
Michael Kassner

For the insightful comments. Just can's seem to get away from those signatures, can we. Image files are becoming popular repositories. I recently wrote about how Evercookies are stored in them.

Michael Kassner
Michael Kassner

If you want to get some good reviews, pay attention to what NSS Labs is saying. It is one of the few that uses real-world testing. I may be biased though, having used Rick Moy as an SME several times.

pgit
pgit

Though I would warn against having government involved in any way. The reasons are too numerous to do them justice in a forum like this. Nothing beats a stand alone, bit-wise hard drive cloner and a good clean image for eliminating the worst offending malware. I offer people the option of making a clone of their hard drive after everything is reinstalled, configured and data is restored. With regular backups of data it's a simple matter of swapping the drives to get them back up and running as fast as possible. Few people take me up on it. With hard drives being so cheap I wonder why that's not a more popular option.

pgit
pgit

There is a Linux project calling itself "iron," which purports to make chrome "even safer" by removing components that communicate with google in the background. One of the key Mandriva developers says this is bogus, chrome is "safe" and who knows who these "iron" people are. If you know someone who has an answer to that, is iron legit, is it better, (?) I wouldn't be alone in appreciating your digging it up... http://www.techgainer.com/iron-browser-a-modified-version-of-chrome-for-better-browsing-security-privacy-and-speed/

SkyNET32
SkyNET32

Him a bit more. I also like to listen to Steve Gibson, and Leo Laporte on SecurityNow! And Paul Thurrott. I think Gibson is very smart and I like how he puts a lot of complicated topics (like cryptography) into laymen's terms for folks like me.

pgit
pgit

Remeber that when ISPs and telcos were handing over reams of private data to the goobermint, it was librarians that stood up to the secretive, unwarranted demands of FBI and others for records of people's reading habits. http://www.democraticunderground.com/discuss/duboard.php?az=view_all&address=102x3300867 That's just one example. I recall an elderly woman in New England somewhere telling them like it is, and they threatened her with jail for expressing her opinion of the course "our" nation is on.

pgit
pgit

I read that "An Overview of Unix Rootkits" study a while ago, I could probably say all I know about them I got from that paper, it set the foundations straight in my mind on what is and what isn't vis rootkits. I heartily second seanferd's recommendation. Packet storm is way cool, nothing more to say but bookmark 'em, or better yet put them on your 'speed dial,' 'morning coffee' or what have you...

JCitizen
JCitizen

but even I say the fanboys at ZDNeT are mactards. Actually almost all the fanboys of all makes and models are retards over there. I can not see how you can stand the new web-design of the site, it makes my head hurt. I can only tolerate just a few minutes of it.

Michael Kassner
Michael Kassner

I will have my Linux-proficient friend walk me through it.

pgit
pgit

It's my understanding a lot of these things wipe their own executable from the hard drive once they are resident in memory, then re-write it for the next boot on shut down. A scanner wouldn't have a chance if it's OS dependent, and scanning system files on the boot media, it would seem. And can you make the registry read only at any point? Maybe when written to disk at shutdown, so during boot it's read only and any rootkit would not be able to erase it's track. But I'm spitting in the wind on this one, I have no idea if such a thing could be done. (some way of preventing the rootkit from erasing it's executable on boot)

Michael Kassner
Michael Kassner

But, the point of this rootkit is that it uses mis-direction. Couldn't that same technology be used to mislead the scanners you mention.

OldGuru
OldGuru

Signature based detection seems to be the only way that does with it's supposed to effectively. Unfortunately with inherent inadequacy of signature-based detection, our best bet is an [i]effective[/i] real-time behavior analyzer, and I yet to see one. Your article about Evercookies was very interesting. It just shows how securing our computers, and information, become increasingly more difficult vis-a-vis ingenious new techniques used by cyber-crooks.

AnsuGisalas
AnsuGisalas

I like the NSS Labs method, it's very likely to be more accurate than standard methods - and more current, too, since they test against what's actually going around out there in the wild wild web right now.

AnsuGisalas
AnsuGisalas

Corporates would put that as a "free additional service" of the "premium service package" (meaning that twice the cost is paid over a period of twelve months). It would work too, especially when someone has a bad instance, receives the benefit of the "free service" and starts circulating the good word.

pgit
pgit

I have a fairly odd mode of speech myself, that I've found actually helps in communicating with people who's primary language is not English. I'm reading the links you provided atm, it does look like iron would be a better choice.

seanferd
seanferd

SRWare develops Iron, and seems to stay more up to date with the Chromium/WebKit source than does Google. http://www.srware.net/en/software_srware_iron.php I assume any Chromium/WebKit browser is safer than Google Chrome by default, until I find otherwise. Not just safer, but less annoying, especially in certain circumstances. Chrome does what Google wants in preference to what you want.

Michael Kassner
Michael Kassner

But, as a writer, I could not get past the website verbiage. I will check with my sources and see what they have to say. It would be interesting to see what Panopticlick says about it.

SkyNET32
SkyNET32

she's very smart, types with two fingers, but she is very very smart, just lazy ;) (I always tease her!) She sees me listening to Steve Gibson and rolls her eyes and says "Ok, I'm bored already!" :D

pgit
pgit

I hang on his every word. Very entertaining and funny, too. How's this for a plus vote: My wife and I listen to security now! together. She knows nothing of computers, but understands the concepts they put across, and finds it interesting and enjoyable, like watching "nature" on PBS, the discovery channel etc. BTW she types with one finger on one hand... it's painful to watch the second hand go over to the keyboard to press shift, then go back to her lap or somewhere arm's length away from the keyboard... back and forth, back and forth. I point out she could double her typing speed if she kept the other hand over the keyboard. Insistence is futile.

seanferd
seanferd

It's the random, warrantless fishing expeditions à la Patriot Act that are the problem.

Michael Kassner
Michael Kassner

We appreciate you sharing your experience with us. It helps put a point on what is really happening.

SkyNET32
SkyNET32

The "props"! :D I will admit though, that given our current privacy situation and its effects within libraries; I have this to say: I am not as privacy oriented as some of my colleagues, although I won't just give up someone's information just because a law enforcement agency asks. On the other hand, if they have due process, a warrant etc, I have no qualms about issuing them what they want. Of course, I am not the one to make those decisions, my Director is (in conjunction with the Library's attorney) and I will say, in fact, I was on staff the day the FBI did come in looking for access to patron information, while I was on the reference desk. He was extremely nice and soft spoken, and I politely told him that I have access to everyone, even you - I'm SkyNET after all. He promptly laughed and asked me if I wanted a job. Apparently someone, who it was traced back to our public access machines was sending threatening letters to some federal judge, somewhere in the mid west if I recall. I told the agent, no worries, I'm sure my Director will oblige. They didn't take my machine but I don't know what became of their investigation. This was a few years ago. I don't have an issue finding out who was on a public access machine if it's been reported to me that they were looking at "inappropriate" material, but I prefer to catch them in the act, which believe me, I have on numerous occasions. I don't however, as per policy, give out information over the phone, ever. If the person is standing in front of me, and I know them to be a regular, they've shown me ID in the past etc, I don't have a problem just looking up their barcode number or whatever..It really depends on the situation and the librarian's judgement. Philip

seanferd
seanferd

I'll even put on a hat so I can take it off in respect. Librarians, concerned about the nanny systems installed for library computers, have fought the good fight on this front as well.

pgit
pgit

"macTard" has a nice ring to it, but we don't want to exclude the phone and pad owners, technically shouldn't it be "iTard?" I agree, the murk at ZDNet is overwhelming any more. It's past the mark of 'diminishing returns' and moved into the venue of pure entertainment. It's bonus if you happen to land on some actually valuable information among the comments. I read a lot of article there, and sometimes I'll throw out a comment, but not for the purpose of engaging discussion. I may comment but I hardly read anyone else's comments. ps- to be fair there are "wintards" and "lintards" in abundance as well. Though fewer in sheer numbers, the lintards more than make up for smaller ranks with a more vengeful fervor.

seanferd
seanferd

I can't stand the new site design. And I knew it was a taste of things to come. I don't mind the colors, though. And reading the articles isn't much of a problem, as I've ignored the forum there for ages anyway. Far too many OS-religious comments from a huge supply of OS-religious regulars. Although I feel like I'm missing out on the comments from the minority intelligent and rational folks with some knowledge who still remain. So, the Mac folks are out-commenting the Windows supporters now? The "with friends like you..." Linux fans have never quite matched the other two groups in my experience. Too bad the good ones are drowned out by all three. I wonder if killfile for Greasemonkey works for ZD. I greatly miss Roland Piquepaille, though. The other regular blogs are still good.

seanferd
seanferd

Weird that OS X doesn't really make full use of ASLR.

pgit
pgit

In addition to rkhunter, other tools you would install and configure before putting a Linux machine on a network would be tripwire and one of the inotify variety of file watchers. http://www.tripwire.org/ http://inotify.aiken.cz/ The fully commercial tripwire is part of a suite of some interesting looking security tools. Being they cost $$$ I haven't done more than window shopping with them. http://www.tripwire.com/

OldGuru
OldGuru

If you install the whole OS in a read-only partition then where do you store the registry? How do you apply OS updates, service packs, etc? What about third-party drivers and antivirus programs many of which need to have close interaction with the OS' kernel? Nice idea, but not very practical. If we let user to flip the switch back to allow the above then we'll be in the same situation as we are now with Windows UAC.

SkyNET32
SkyNET32

after a clean install, you have all your programs installed, data, etc, and when you're done, you flip a switch to make the OS read only; any activity by a user (browsing, creating/saving documents, music video etc) can be retrieved, read/written to a separate partition or drive, leaving the OS totally isolated, no? I'm sure this idea isn't new, and I'm not thinking of virtualization because doesn't certain operations, (like network calls) have to go through the VM sandbox? I'm thinking of totally rerouting everything (misdirection, for use of a better word) but what do I know.... :D

OldGuru
OldGuru

from the hard disk when they were running in memory; I could just boot the system, wait a while to make sure rootkit(s) are running, then unplug the computer and all the rootkits would be gone!

santeewelding
santeewelding

With my ear pressed to the door, I learn more than I probably am entitled to learn. Thank you.

OldGuru
OldGuru

because when it identifies OpenVPN client as behaving like a backdoor that tries to bypass LAN or another program that tries to "invisibly" send out information, it doesn't provide any clue (such as the destination IP address) so I can tell if the program has been compromised or it's just performing its legitimate function.

seanferd
seanferd

I may have to try it myself, but probably not in the near future.

SkyNET32
SkyNET32

behavior analyzer would be a self aware AI, imo. Its the only way I can see that software is going to be able to thwart, to use Mr. Kassner's words, our "human cleverness". But that's just me. A self-aware AI seems like overkill to me, just to take care of malware, seeing as what else an AI of that magnitude would be able to do - if you believe the Kurzweil's of the cyber world ;)

OldGuru
OldGuru

I downloaded it for trial and waiting to see how it deals with the little buggers!

OldGuru
OldGuru

I searched for Namutu and didn't find anything on CNET (including download.com)

JCitizen
JCitizen

made my Emisoft, the makers of A-squared and Online Armor, called Namutu. It is kind of like using the free version of WinPatrol, but seemingly more powerful. It is strictly behavior based, uses very little resources, or RAM that I can tell. It took it just a few seconds to find my DRM spies on my PC. I had to exclude them from "protection" just so I could use my cable and blu ray. It seems lightning fast at what it does. So far it seems awesome!! I can't use Online Armor on Vista x64 so I'm pretty excited about testing this. So far so good! I think the giveaway ended this Sunday.

OldGuru
OldGuru

if you promise to do the same! But I have a feeling that by then the bad guys will have already found a way around it.

Michael Kassner
Michael Kassner

Please let me know. I have been researching what is needed to pull it off and the requirements are steep. Still, I have no doubt that it will happen. Glad you liked the article. The cleverness we humans exhibit never ceases to amaze me.

Editor's Picks