Microsoft emergency update: Malware Engine needs, erm, malware protection Microsoft has posted an out-of-band security update to address a remote code execution flaw in its Malware Protection Engine. Redmond says the flaw, dubbed CVE-2017-11937, has not yet been exploited in the wild. Because it is an out-of-band critical fix, however, it should be installed as soon as possible. For most users, this …
"You couldn't make this stuff up."
No you can't make it up. As it turns out, the software on your computer is bloody complicated and funnily enough it isn't perfect. I don't have MS' stats but I do know that the Linux kernel is roughly 70,000 files with rather a lot of LoC.
As it turns out, bugs happen.
I don't have MS' stats but I do know that the Linux kernel is roughly 70,000 files with rather a lot of LoC.I think you are missing the irony, this is not a bug in the Operating System itself, the kernel or other necessary modules/process (e.g. file system drivers) that is needed to make a computer perform useful tasks for an end-user. This is a bug in a separate non-OS application that you could - from a using the system perspective - quite happily live without. This applications specific job - it's one and only reason for existence - is to protect the user from opening files containing malware. And yet, that application, in the process of checking a file for malware, becomes the vector that enables malware to not only infect the computer, but to gain privileged access along the way.As it turns out, bugs happen.
I can't quite muster up the outrage.
In a time of throw-away-your-motherboard-and-anything-ever-connected-to-it vulns in the Intel chips, it seems almost quaint to worry about antivirus being intrinsically woven into anything as high-level as the operating system.
Underlying this, and maybe built in to the OS, is the simple fact that this programme with a specific job to do can trigger and allow the running of a programme that is unconnected. i.e. the file being scanned is allowed to climb out from under the microscope. I don't have the skills to do more than believe this is how it should be done - but surely a file being scanned shouldn't be allowed to do anything until the scan is completed.
I think I'm with you on this one.
Given that AV should isolate anything being checked, scan it and quarantine it if in doubt, how the hell does a "bug" get to execute rogue code?
Not doing something intetesting like "Let's just run this in a sandbox and see if it tries something iffy." by any chance? Followed by "Oops!".
Otherwise how does it get even near executing files that it is checking?
Thanks, yes, in my naive way I would expect any scanning software to examine the code, not run it. Otherwise it's no better than when those detectives in old American cop dramas stick a finger into the white powder and taste it.
Always wondered what would happen if someone tipped the cops off that cocaine was being transported in drums marked as xxx-Cyanide (the xxx being something combined with the cyanide that'd give the resulting compound a whiter colour while still leaving the lethality) - if they really did things like in the movies how many would perish before they realised tasting even a tiny amount of "strange white powder" is a very bad idea? (also IIRC wouldn't is somewhat resemble anthrax spores? (not that you're transport anthrax in large bricks but a small packet (enough for a druggy to get their fix of cocaine) of flour mixed with a few spores...)
Even as a kid I thought "that's silly, what is someone poisons it?".
That is how the software is designed (compartmentalised).
The issue is that if the file being analysed contains some arcane pattern of data that causes the analyser to crash, then all bets are off about what happens next. That is a common tactic that hackers use on any software.
It is not possible to test the software against every combination of data that could ever be fed to it, so the software would be vulnerable to this risk, as is the case for a lot of software.
Some data and calculations or logic on that data need to be fed into the processor together. There is no way around that.
> Otherwise how does it get even near executing files that it is checking?
Typically it could be something like: it was trying to copy N bytes from the file to memory, but N is misinterpretted as 255 instead of -1, so the bytes overwrite a location on the stack that contained a return address. So when the function returns it starts executing code from that address, which could also be from the malicious file.
I completely agree but note that you could make exactly the same argument for a picture file, a document or even an http response.
The classic case is finding an input of a size and nature that exploits a processing allowing it to overrun its process space. One technique is the so-called NOP sled... A huge number of no-op byte codes preceding the code to be executed. Then if you can cause program execution to jump anywhere into the sled range, the code following it will be run.
Ahhhhh gotta love examples of true irony.
Remind me again, why isn't this app compartmentalised? The virus scanning part, running as an unprivileged nobody user, blind and limbless, unable to do anything but listen to a byte stream whispered in its ear, and reply 'clean' or 'infected'?
Ho hum. I've got some fonts to display. Better fire up kernel mode.
I remember security researchers inquiring about the lack of robust sandboxing in Microsoft's antimalware engine and I believe the response they got was that the Microsoft engineers understood and agreed, but hadn't be able to get that implemented yet. That was a while ago, and clearly they (or more likely, their bosses) haven't given it much priority in the intervening time.
Because it is an out-of-band critical fix, however, it should be installed as soon as possible. For most users, this will happen automatically.Odd then that when I fire up my two Windows systems to look for this, only one of them finds it.
And even that one has it scheduled behind a "2017-11 Cumulative Update" that has been sitting at a status of "Preparing to download - 100%" for over 15 minutes without progressing.
I'm not sure I agree. Would this mean that more hardware is out of the control of the user/administrator? Imho, that would be the last thing we need. I don't want more ME type issues. I want more access to hardware and the firmware that runs it. I know software can be hard to get right, but buffer overflows and many other bugs have been an issue since the beginning of software. I believe education is the issue. I also think that although everyone deserves the same shot at going as far as they possibly can with a great education that educational standards have fallen over the last 40 years.
I work as neither a programmer nor a sys admin, but if my education premise holds true for those fields as well then there are too many programmers and admins who should be doing other things; but, a flooded market certainly helps drive down wages for all but the very best in any field and maybe them too.
"I'm not sure I agree. Would this mean that more hardware is out of the control of the user/administrator? Imho, that would be the last thing we need. I don't want more ME type issues. "
No, ME/SecureBoot/etc aren't security features. This would work a lot more differently.
Essentially you'd have something like tagged type architectures where the CPU stores values along with their types. Essentially the CPU would be able to know where memory areas end. Additionally you could add tags like "private, not to be put on the network", and functions that encrypt data could add an "encrypted data" tag to it. That way you could put a filter on your network card to only let out private data that's encrypted. Such filters could even work in hardware.
However the big problem is that you loose all compatibility with existing systems. Considering the number of written from scratch full blown operating systems having been developed in the last 20 years was 0, that's quite some work to do.
There are constructs using CPU traps (eg exceptions) that allow the CPU to catch many such issues.
However, given that the only thing the OS can do is to kill the offending process, the cure can be worse than the disease.
Aside from that, the CPU often isn't even involved as these are DMA transfers.
When I was still young there were many projects that proposed solutions that provided protection in hardware - IBM's SWARD had hardware protection against 19 of 21 programming issues (if my failing memory is correct :) ).
As I recall, the hardware technology at the time was just not powerful enough to make any of these proposals yield acceptable performance - although I am reminded of the comment in "The Elements of Programming Style" that turning off (software) array-bounds checking allowed the generation of faulty results as fast as possible.
Perhaps we should be digging out research material from way back and reexamining it for implementation now.
Nah, Microsoft lets you shoot everyone in the foot in one go.
To take the analogy further, the fellow on Earth-113 who is still using Windows 98SE will find that the rogue update he installed using the tunneling scanner caused the system to break because it fixed a vulnerability that never got added because the programmer went on holiday a day earlier and the rest of the team picked up the glaring error(s) and fixed them before release.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
