New attack bypasses virtually all AV protection Researchers say they've devised a way to bypass protections built in to dozens of the most popular desktop anti-virus products, including those offered by McAfee, Trend Micro, AVG, and BitDefender. The method, developed by software security researchers at matousec.com, works by exploiting the driver hooks the anti-virus …
Nice hack! Based on the multi-thread timing issues in an article a couple of weeks ago.
The AV software should not "pass" any code that is in writeable pages, or pages that non-privileged code can change the access of. The first test is fairly easy in Windows, I think, but I don't know about the second.
I thought about this kind of Tom foolery some time ago. I think about a lot of things I am too lazy to investigate, or lack the skills (read patience to learn those skills) to achieve.
I have often wondered if indeed this kind of AV hoodwinking has been accomplished already.
To be honest I don't really care, my experience and understanding of IT/computer security tells me NEVER to store anything illegal, shameful or embarrassing on a computer connected to the Internet. If one needs to bank online then use an account that is usually empty and transfer cash into it as required.
I think I am smart, I think I am secure, but I only think these things, it doesn't make them so. There are far smarter hackers out there than I.
Trust me I am not an MP.
It's a wonderful war!
This can be veeeery easily fixed - you copy the parameters from user pages, you verify them, and then you call the system service with your copied parameters. If the system service is returning some data in user-allocated memory, you allocate some page-able kernel memory, get the system service to write what is requested there, and then you copy it back to user-supplied pointer. Problem solved in ~10 lines per function. I expect this to be fixed in all those packages before Monday.
... the memory page allocation service is itself is exposed via the very same SSDT, though.
If you tell the SSDT to write data destined for user memory to a kernel-constructed/reserved page, then have the kernel copy the data from the kernel page to the user page (or adjust the pointers and page permissions - same difference), the SSDT still needs to provide information (or be provided information) about the page and security context switch, so that when the hooked service unwinds its call stack, the calling app knows where its data is.
Since the SSDT would still be involved, I don't see how writing the data back to a kernel-reserved page first would help anything...
Ok, firstly - SSDT stands for System Service Descriptor Table, so you can't 'tell' it to do something and it doesn't 'provide' information except for adresses of kernel syscalls - are you sure you know what you're writing about?
All of kernel memory (0x80000000 and above on 32-bit systems) is shared between different processes, so once some data is copied there, it doesn't matter which process' pagetable we're currently using.
FYI, all syscalls are expected to copy memory to kernelspace prior to doing something with them - so as to prevent race condition between syscalls running on IRQL lower than DISPATCH_LEVEL and for instance userspace code - just imagine, if this was happening, process could call OpenProcess on something it can access, then try to race with it to gain access to winlogon.exe. THIS IS NOT THE CASE - you can try it, coding it is just a few while loops.
For your information, all userspace<->kernelspace memory copying routines do their job at at least DISPATCH_LEVEL, which means they cannot be pre-empted. Even Microsoft's own docs state that you should always capture the user-space buffer because of possible race condition (see here: http://download.microsoft.com/download/D/1/D/D1DD7745-426B-4CC3-A269-ABBBE427C0EF/SYS-T774_DDC08.pptx ), so this bug means that people implementing the syscall filters failed to understand what this document says - that is, for all processing in kernel mode, the data should be copied into the kernel space AT THE BEGINNING and at one point only, processed and then returned to user, also in ONE POINT. What the AV vendors did was just pure laziness, I presume.
Citation from http://www.matousec.com/info/articles/khobe-8.0-earthquake-for-windows-desktop-security-software.php
" ....
The problem
The code of system services runs on IRQL PASSIVE_LEVEL which also applies to their hook handlers. Code running at this level can access pageable memory and, when the scheduler decides, might be preempted by another thread. And the scheduler plays the key role in the argument-switch attack. ....
Before the scheduler switches back to the hook handler, many threads might use the processor for some time, including other threads of the application that called NtLoadDriver. ....
When the scheduler switch thread context back to the thread executing the hook handler, the original system service is invoked and might load driver which name was not subject of any security check made by the security software. And this is exactly how the argument-switch attack works. .....
"
The bomb is hidden elsewhere. It can not be deactivated by changing dispatch priorities.
best, Hans Adams
I'm saying that the bug can be deactivated by using data *copied* from the user-supplied buffer when calling the actual system service from within the hook. It should also use the Zw* version vs the Nt* version of the service after careful parameter validation. Then, there's no way user-mode code can change that data after it was verified - as the exact same parameters that were passed to the hook are passed to the system service. The problem is here:
NTSTATUS NewNtLoadDriver(IN PUNICODE_STRING DriverServiceName)
....
status=OldNtLoadDriver(DriverServiceName); <--note how they're passing the usermode pointer again
......
The second line quoted should be:
status = ZwLoadDriver(driver_name);
where the driver_name variable is their kernel-mode buffer. (it will also need moving the declaration of driver_name a bit higher so that it's declared in the scope of whole function).
According to MS's docs, the only difference between Zw* and Nt* function couterparts is that the Nt* version checks the parameters for having invalid pointers, etc. junk, copies them to kernel space and then calls the Zw* version. As long as microsoft didn't implement any deviations from this behaviour for specific functions, my snippets above will prevent the bug from being exploited and won't introduce new bugs.
I provided some info in different IRQL levels for the information of previous commenter, as he clearly has no idea what is he writing about.
"""I will point out that saying "we're immune because we're unpopular!" is not a good strategy for an OS, one way or another"""
I'll pass the message on to Ballmer.
Linux is immune because it exists primarily outside of the commercial sector where everything is heavily influenced by marketeers and other scumbags to which technology is more a way to boost ones stock portfolio in the short term by means of lofty unrealistic promises than it is a useful tool.
Repeat offenders in the marketing-above-technology diarrhoea slurp-o-thon are the likes of Apple, Facebook, Twitter, Microsoft, Bose, Sony circa 2000+, "the music industry", "the government" and supporters thereof.
"I will point out that saying "we're immune because we're unpopular!" is not a good strategy for an OS, one way or another"
You'll be glad to hear that that has NEVER been a strategy for Linux or FreeBSD
@cornz1 - posted from an apparently unusable computer - which is also unusable for e-mail, video watching, word processing, spreadsheets, audio and video editing, Google Earth, software development, PCB design, PIC programming, protein modelling, photography including RAW development for my shiny new Canon 550D, remote access to my home server and wife's school's Windows server, etc,......... get the idea ?
No - no AV here either.
Yes, of course, how silly of me, as a minority linux user you can walk into any high street store and buy software for you computer. And your point is? My windows box does all yours does (and more!!!) only i dont need to spend hours pissing around writing and configuring drivers to get it to do it.
So, yeah, i am well aware what a computer can do, its just mines does it with a lot less hassle.
And if you believe that any linux distro doesnt require AV software, youre a bigger goon than you first appeared to be.
If someone were to try and develop security software for Linux that has this flaw, the community would give them a good talking too as soon as they noticed. This particular issue and the solutions to it are well known in the Linux community, and the kernel security frameworks are all designed not to be vulnerable.
1) It's a trojan approach not a virus - no one is claiming Linux is immune to trojans
2) I can't get it to work sensibly -the downloaded program which has to be a script not an executable ( I used one of mine off my webserver which is set world executable ) is saved in tmp but after e-mailing the executable desktop link to self the icon is automatically set not executable and any attempt to click on it gives a warning message and indeed the text of the command.You'd have to click to accept that you trust the program at this point to launch it and set it executable This under KDE/OpenSUSE 11.2
Well I would think twice if your run Wine or any other Win emulators. Make your Win EXEs are clean, before you let them lose through Wine.
Obviously if running Wine you run malware through Wine and it breaks out of the emulator directory and goes on a rampage through your home directory, that could be unpleasant.
Then again, you could be one of those divs who runs Wine as root, then it really could be game over...
Linux/Mac are not perfect, as we get more "cross-pollination" of O/S executables, someone, somewhere will have a field day! I do run Linux and OSX, I just keep my Win EXE emulation usage down to a bare minimum, just in case.
So for this attack vector to work, to allow you to run rogue code, the computer must already be running your rogue code. Then you load some program, let the AV scanner scan it, and then replace it with different code that you already have in memory for that to be run instead?
So the machine is already compromised, and the rogue code somehow already made it into memory, and your compromising program already has write access to random areas of memory?
It's a long time since I looked at the internal workings of Windows and PCs, but it smells fishy to me. Is this that big?
The implication of the linked article is that the API hooks used by typical AV software are all in user-space and may be bypassed by code in the process that they are trying to control. Apparently, the industry switched over to this mechanism because implementing those hooks at kernel level, which would be secure against this kind of attack, was too hard to get right for their poor programmers. (Aww!)
As a piece of design, that would be quite stonkingly embarrassing for the AV industry if it were true. As another poster notes, the basic attack is very old. The need to copy parameters was known as far back as the 1960s and Intel built such a mechanism into hardware for the 286. Any programmer who doesn't know about it really shouldn't be allowed to distribute kernel-level software.
However, unless MS have pitched this hook mechanism as secure (rather than merely convenient for use by well-behaved software) it isn't an OS-level vulnerability.
These hooks are all in kernel mode. The problem is what I said above - all of those serivices operate at IRQL_PASSIVE, which means that they can be pre-empted by the scheduler at any time.
The hook copies the data from userspace into it's buffer and verifies it. But then, it passes the original userspace pointer to the hooked function, which then copies the buffer again to kernelspace - as the hook code can be pre-empted by usermode thread, the userspace buffer can be changed before the hook execution finishes - BAM, exploit. I provided explanation how to avoid it above.
OK. Thanks for the explanation. (We seem to have posted at exactly the same time.) This would make it Microsoft's fault rather than the AV vendors (since kernel mode coders really ought to know better) and also really easy to fix.
One remaining curiousity: How could a 1960s-vintage design error pass Microsoft's Secure Development Lifecycle code reviews and make it into, of all things, the Grand Central Dispatcher for *all* system services? I mean, that code must have more eyeballs on it than most of your average Linux distro.
Any data in userspace can be paged in and out during execution, so you need to be able to access any pages that are in the pagefile. To do it, your thread must allow for respective interrupts (namely 14) to be handled, and on Microsoft's system this means running at passive IRQL. Otherwise, the driver would have to manually page-in any buffers that we're paged out - which doesn't make much sense because of code overheads. The SDT hooks were not officially endorsed or supported by Microsoft, especially when it comes to user-mode hooks (as there are two SDTs - one for kernel mode and one for user mode) - this changed as it became so widespread. You can no longer hook SDT in x64 versions of Vista and above due to PatchGuard - which shows that Microsoft hates this method. Linux stopped exporting it's sys_call_table (which works in a very similar way) with kernel 2.6.0 which means legit modules are not using it (rootkits still do, though).
As for the "single entry" thing - that's how it's done in all Intel architectures - you need some way to transfer execution from ring3 usermode code to ring0 kernelmode code ; you only have hardware -limited number of interrupts which can do that (many of which are used to signal some hardware functions, like division by zero error or page fault), so there's a limited number you can use. It's only logical to use a single one for such purpose. Later on, intel introduced the sysenter/sysexit pair of instructions which allows you do the transition much faster than via an interrupt. All normal systems running on intel architecture use this - so if you want to blame someone (and I don't think there's a reason for that), blame intel.
Although the basic concept of making changes to parameters to system calls and sneaking those changes past an AV program would not require a higher privilege level, making an actual system call that actually did anything would. Therefore the rogue application would already need to be running at Administrator level to actually do anything with this flaw.
Any decent virus writer checks his work against all major AV applications before releasing it into the wild. Meaning the code aint gonna get flagged any way.
So - the point of this code would be to prolong the life of the virus after a detection signature has been created?
Or to try and sneak in an already known virus? (sounds pointless and amateurish)
The Norton Removal Tool can (a free download from your local Symantec site). It's actually rather good at doing this and is possibly the only uninstall tool issued by a software maker that really does remove every last squeak of their bloody products without leaving you to hoover out the corners afterwards.
If you change your Norton upgrade process to: Run removal tool / install new version of the bit you're replacing / reinstall all the old things you want back*, you can wave goodbye to all those pesky b0rken upgrade issues that Symantec are so justifiably famous for.
I'm forced to wonder why, given the bleedin' obvious implication that they *can* get it right when they want to, the supplied uninstaller doesn't though.
I'll leave it to the assembled multitudes to ponder the irony inherent in the fact that the most reliable and fully functional piece of code in the Norton product lineup is the tool for removing their products.....
*You may need to add "call 'em up to reset their crappy licensing system for all the reinstalled old stuff" at this point :-(
I found another hole in this here swiss cheese! Even after I filled all the other holes whith spray cheese! Amazin', innit?!?
I'm not saying you should use $brand replacement cheese over this, but I am saying that while this may be yet another really clever hack, it's also a good illustration of why ``investing'', even under the ``security'' moniker, in broken systems is unproductive in the extreme. The problems with redmond's finest begin with that it is an unorganised jumble that has grown holes down to the core and don't end with that it is a monoculture. We desperately need multiple viable platforms, solid interop, and systems with some actual design in them.
Oh, and people using those systems that aren't pavlov-dogged into accepting every catastrophic failure with simply retrying and blindly clicking on every OK button in a user-friendly fasion. Shush you, I can dream, can't I?
The Virus Writer's Handbook: The Complete Guide
(c) 1992 Terminator Z (AKA Harry McBungus)
http://vx.netlux.org/lib/static/vdat/tumisc09.htm
[...]
5.22 Disinfecting on-the-fly
[...]
These are the fundamentals of the stealth capability - when to disinfect. On all calls to open the file, add the name & handle to a "database" in free memory after the end of your virus. When it comes to close-time, simply scan your database for the handle and re-infect its corresponding file, and erase that entry from the database. How simple can it get? (See? It's a lot easier in theory than most people imagine!)
[...]
...how big is this Cd you propose...
100's of thousands of drivers,
100s of thousands of programmes.
Then where do you keep you saved files? Config settings etc etc etc... ooo there's your weak point.
Yes live cd's are ok for a short test or quick use, but don't fancy running a 24/7 system off them...
Now I'm off to use Linux instead of Windows.
Right critical business app....Linux edition.
Ah it's doesn't exist. Oh well, time to scrap £3/4 million of hardware then and try to get an inferior feature set, poorly implemented, badly supported, user (and admin) unfriendly product running instead.
i have pondered on this for a while already.
simply add a write-protect switch to a harddisk.
An Os would create 2 partitions. One for the system , one for the application. the write protect switch ( physical 2 wires that need to be shorted ) blocks write access on partiton 1.
To enable writing one must open the switch and then reboot. more on that later.
the system creates a folderstructure which is a logic OR of the directory in partition 1 and partition 2. if duplicate files exist partition 2 takes precedence.
an example
part1\windows and part2\windows. there Still is only a C:\windows but it is made from the OR of part1\windows and part2\windows. if the file kernel.sys is present in both then the one in part2:\windows takes precedence ONLY if we boot with protection ON.
this mechanism is totally transparant. If you install something new it goes to part2 if writing to part1 fails.
Now, here is second element. if you reboot the machine with write protection off then the machine will only boot using files from the secure partition. There will still be a logical or but this time files from partition 1 take precedence.
This allows a system to always boot from a 'trusted' partition.
file tools would be avaialble to kill files in the non secure parititon.
so if you get infected : the infection can only live in partition 2 since it is the harddisk that prevents writring to partition 1. ( physical hardware. not defeatable software).
if you now do a clean boot the system will not have loaded the infected file. Run a diff and destroy the infected file from the non-safe partition.
The system could be done in such a way that once the switch is closed this cannot be undone until the next boot. (simple set-only flipflop logic. only a powe cycle can reset)
that way the machine can always boot fomr the clean partition. as a last step it would eecute a call that sets the flipflop and now runs the system in partition or-ing mode
this is a technique that can be easily implemented. only some file tools would be required. a few tweaks to the filesystem to grab file sform the correct partition depending on switch setting and a harddisk with 2 extra pins on the back. what is the industry waiting for ?
So, how does this virus get itself run in the first place?
My AV reports on files containing viruses before I even open them, blocks email with viruses as the mail client downloads them and I believe it scans incoming http type traffic for me as well (although I haven't tried to check that).
So, bearing in mind that the AV software still has most of the attack vectors covered, the fact that a program that hasn't already been detected as a virus isn't detected as a virus when it runs is hardly surprising, is it?
For those of you concerned about how easy it is to "fool" your AV software, even "clever" AV software, look for the EICAR test virus. Download it to your PC and try changing a few bytes of the "text message" portion within it.
Last time I tried that, about 2/3rds of the AV software I tried it with were completely fooled.
The few that weren't fooled did manage to be confused by simple tricks like renaming the file from .com to .txt. If you wanted to, you could probably put the file in an NT "stream" and hide it quite well.
Basically, you're screwed. It's only the incompetence of virus writers that has kept everyone safe so far but with the financial gain element of viruses becoming easier to realise, I think it's going to get a LOT worse before it gets better.
I don't trust the AV writers to be the solution. It's down to the OS and the privilege models that they use.
That's why Linux is generally immune, not because it's in some way better, but just because you don't need to run everything as root. The difference between user and system are very clearly defined. So, you can screw up one user account, big deal. Just delete it and move on.
The problem now with Linux is that there are more and more non-technical users who don't understand the model and still insist on installing packages with sudo instead of putting them in their own home dir. Encouraged by the infrastructure of apt/yum/etc....
At least with Linux you can decide which software repositories you trust the QA of, and the PKI attached to signed packages means you have a certificated supply chain for all the software that gets installed and executed on your system. Sure you can still make a bad decision to trust a supplier who provides their own repository and allows bad stuff it, but if you are worried about that you could always setup virtual machines for less trusted software suppliers who have not yet got their software packages accepted by the mainstream package repositories.
No system is immune against an end user who doesn't think about trust issues while knowing enough to download and execute code other than in a transitory sandbox (e.g. as with Javascript).
First, it is NOT the "EICAR test virus", it is the "EICAR test file". A file that major anti-virus developers have agreed to detect in the same way as they detect real viruses. The point is to have a safe program that can be used as a standardised test that anti-virus programs are, actually, installed properly and checking files.
The definition specifies that NOTHING in the file can be changed - at one point, some sneaky virus writers created viruses that had the EICAR test file at the beginning, followed by their dangerous code.
The file was not designed as a test of AV software's ability to detect "variants", and it is a seriously-flawed testing methodology to use it for that.
"The problem now with Linux is that there are more and more non-technical users who don't understand the model"
'ere we go again. Techie snobbery, everyone else who doesn't have technical knowledge is inferior etc. etc. Let's make a virtue out of complexity etc. etc. What do you want Linux to become? Do you want it to increase in popularity or not. Many "don't want to understand the model" and shouldn't have to. The funky computer should itself sort that out - just like the one in the 80s Ulysses cartoon. I'm with Shuttleworth and Ubuntu on this. Oh yeah and don't get me started on the nerdy Linux names: G-this K-that etc...
"still insist on installing packages with sudo instead of putting them in their own home dir. "
And why is that? If it was just as easy, if not easier to install the package in their home directory without needing sudo, then don't you think they would do it? Obviously its not so easy that's why they do it.
"Encouraged by the infrastructure of apt/yum/etc...."
Well that is a problem: the plethora of distribution and installation methods. No benefit in this duplicity. If there was just one OR a standard for them to follow then it would be simpler.
Go on, thumb me down.
So, for this trick to work, the malicious code that does it has to be run in the first place, right? 'Coz if it isn't run, it won't do a thing - neither this trick, nor anything else.
Hello? Ever heard of on-access scanners? Those are programs that run on your machine all the time and scan every executable you try to run (or even access). Either it is malicious, or it is not. If it is not - no worries. If it is malicious, either it is known to the scanner, or it is not. If it is known to the scanner, it won't be allowed to run, period. So, no worries, it doesn't matter what it tries to do.
If it is not known to the scanner, it will be allowed to run. This is bad news. But how is this trick relevant? First law of computer security: if you run the bad guy's program on your machine, it's not your machine any more. Once running, the malicious program can do ANYTHING without resorting to this trick at all. It can deactivate or delete the virus protection, it can destroy files, it can sniff data - ANYTHING.
Ergo, this trick is totally irrelevant.
KHOBE can't be described as a way that malware can be installed on computers.
What Matousec describes is a way of "doing something more" **if** the malicious code manages to get past your anti-virus software in the first place.
In other words, KHOBE is only an issue if anti-virus products such as miss the malware. And that's one of the reasons, of course, why security vendors offer a layered approach using a variety of protection technologies.
How can that be bypassing?
There's a good write-up on this by my Sophos colleague Paul Ducklin:
http://www.sophos.com/blogs/duck/g/2010/05/11/khobe-vulnerability-earth-shaker/
Ever heard of a zero-day attack? Actually getting malicious code onto a PC does require some effort, but it is a truth universally acknowledged, that a single man in possession of a good erection must be in want of online porn, so why not just ask them to install it for you?
Having done that, you can then try various privilege escalations against the system. That's harder, but with the AV disabled you can use *known* attacks for this bit.
"That's why Linux is generally immune, not because it's in some way better, but just because you don't need to run everything as root. "
Neither do you need to run Windows as Administrator. Windows users are just accustomed to doing that and most of them start bitching if they have to handle an Admin and a "Normal" user. People don't want to know how to secure their PC, they don't want to spend time for secure operation (such as switching to Admin and back); all they are willing to do is to shell out money for the antivirus product.
It feels good, but is in reality very ineffective.
A good operating system and o.s. configuration is like physically searching an airline passenger while virusscanners are like those "no-fly-lists".
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
