Slashdot Mirror
New IE Zero-Day Being Exploited In the Wild
wiredmikey writes "A new zero-day vulnerability affecting Internet Explorer is being exploited in the wild affecting IE 9 and earlier. The vulnerability, if exploited, would allow full remote code execution and enable an attacker to take over an affected system. Security researcher Eric Romang discovered the vulnerability and exploit over the weekend while monitoring some infected servers said to be used by the alleged Nitro gang. To run the attack, a file named 'exploit.html' is the entry point of the attack ... According to analysis by VUPEN, the exploit takes advantage of a 'use-after-free vulnerability' that affects the mshtml.dll component of Internet Explorer. Rapid7 on Monday released an exploit module for Metaspolit which will let security teams and attackers alike test systems."
I'm shocked. Shocked I tell you.
... as long as it doesn't strike in those first few minutes where I have a freshly installed system and am using IE to download FIrefox (IE is great for this, by the way!) ... then I should be safe!
Been saing for years that if we'd just get rid of day zero on the calendar that so many security concerns could be solved, but instead we get yet another vulnerability. How did this happen on day 260?
Both.
One of these devs was on the job.
sysadmins and parents of newborns get the same amount of sleep.
After all, you're right - there sure seem to be a lot of Day 0 vulnerabilities. If programming languages just started counting from 1 like sensible people do, this could all be avoided.
#DeleteChrome
of shoddy browser security. Could this not be "solved" with proper sandboxing? If there's legacy code to support (this has been cited many times in the past for reasons why), please, please fork IE into two branches: IE Classic or whatever that's fully backwards compatible, and an IE Lite that's completely sandboxed and locked down for wide-spread corporate deployment.
body massage!
I have a question. Does the exploit work on Win 7 machines or just Win XP?
Yes I RTFAed. It doesn't really spell out what combo of IE and Windows are vulnerable.
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed H
From TFA:
First, a file named “exploit.html” appears to be the entry point of the attack, which loads “Moh2010.swf”, an encrypted Flash file that it decompress in memory.
According to AlienVault's Jaime Blasco, the payload dropped is Poison Ivy, as was the case with the previous Java zero-day. Poison Ivy is a remote administration tool (RAT) that was used the Nitro attacks that targeted chemical and defense companies. Interestingly, after exploitation, the attack loads “Protect.html”, a file that checks to see if the Web site is listed in the Flash Storage settings, and if it is, the Web browser will no longer be exploited despite additional visits to the malicious site.
Namaste
and probably Vupen already sold it 10 months ago to , Ebay style.
Some say a diamond is forever.
I'd say the same about "the zero-day season" at least with respect to systems like Windows as we know it + commonly used 3rd party applications as we know them.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Running web browsers in a well-written sandbox with only very careful access to "the outside machine" will help keep browser bugs from turning into system-wide vulnerabilities.
Sure, someone may take over your browser and turn it into DNS-generation-engine, but once you quit your browser, anything left over will require a social-engineering attack ("download catpics.exe and after you quit your browser, run it!") to continue living.
While no sandbox is perfect, there is (hopefully) a smaller and better-engineered code base to maintain.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
If there are no practical, well-understood or at least vendor-supported work-arounds, then for the vast majority of people, it's still a "zero-day."
Hopefully MS and the other affected vendors (e.g. Adobe) will announce a practical work-around within a day or two.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I think this actually requires you to visit a poisoned web site.
So, unless the web site or torrent that you are getting Firefox from is compromised, you should be okay.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
How is that possible? Isn't "new" and "zero-day" mutually exclusive?
Yes I RTFA and didn't see any information on whether IE9-64 is affected. Pretty lousy of the tester to not bother indicating if the problem is only with the 32bit version as the 64bit has a better baseline security configuration. Due to these issues, it's just one of the reasons I also use Palemoon64. Improved security such as full ASLR along with DEP support so I'm hopefull this does not affect IE9-64 due to the limited number of folks actually using it.
Mod me up/Mod me down: I wont frown as I've no crown
So as long as I don't visit a page called exploit.htm I should be ok?
Isn't IE that tool people use to download Firefox?
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
does anyone actually use IE when they don't have to?
stephen
Does this exploit work if you're running a modern Internet security suite such as the new Norton Internet Security 2013 with all anti-malware definitions up to date? Mind you, my default web browser on my desktop and laptop is Google Chrome 21.0.1180.89, the current "stable" release version.
But I thought they turned on that "Do Not Hack" HTTP header??
Geeks like to think that they can ignore politics, you can leave politics alone, but politics won't leave you alone.-rms
This exploit gains the privileges of the running user on Windows Vista and 7. The entire point of all the "allow/deny" popup BS with UAC was because they wanted to restrict processes to the lowest privilege necessary. IE is supposed to be a high-risk, sandboxed application and yet this exploit magically gets around it and gains access to the full user's account, which probably has admin rights on the machine. MS does not understand security. You don't start out by giving a user admin rights, you make them ask for it, a la 'sudo'. UAC starts out by keeping the user an administrator, and dropping the rights for new processes and trying to intercept when those processes need higher access so that the OS can display a verification prompt. Since Vista, this has been exploited over and over again. The only way to be safe under windows is to always use a low-priv account, and type in the full username/password of an administrator whenever the UAC prompt comes up, and that is a terrible user experience.
True, true. And simple also. Just have all the routers do DPI on the traffic, and if it is from a Windows machine, then just drop the packet.
You are being MICROattacked, from various angles, in a SOFT manner.
Install Linux.
I thought PCs didn't get viruses? Oh wait, that was Macs.
PC stands for "Personal Computer" and macs are PCs. Some PCs get viruses... the ones running Windows. Any computer can be trojaned or taken over by other social engineering, but Windows is the only OS prone to drive-by infections.
Free Martian Whores!
Managed / memory-safe languages aren't a guaranteed protection, though.
First of all, there can be bugs in the runtime that lead to possible exploits. I have a friend who manages to generate segfaults in Java about once every two weeks (no idea how many of them are the same bug being hit multiple times; maybe all of them). In case you're confused, a segfault (as opposed to a NullPointerException) means the runtime thought it could access the memory there, after running all its checks... and found out otherwise when it tried and the CPU had to slap it down. The eqivalent term for segfault on Windows would be "access violation" and in both uses, it boils down to a security bug , potentially exploitable by triggering memory corruption. For that matter, JavaScript itself should be memory-safe.
Which brings us to the second issue: when you're trying to JIT-compile a script, the actual processing of the script is done in the compiler. You could write all of that in the safest language in the world... and it wouldn't do you any good if there's a bug in the compiler's code generation (note: not in the parsing of the script) that causes the resulting code, when executed, to be memory-unsafe. It's much, much harder to verify the safety of generated code (for a reasonably complex language; JS certainly being one) than it is to verify the safety of the code generator itself (even if written in C++).
There's no place I could be, since I've found Serenity...