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!)
[...]
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
