40 Windows Apps Said To Contain Critical Bug

CWmike writes "About 40 different Windows applications contain a critical flaw that can be used by attackers to hijack PCs and infect them with malware, says HD Moore, chief security officer at Rapid7 and creator of the open-source Metasploit penetration-testing toolkit. Gregg Keizer reports that the bug was patched by Apple in its iTunes software for Windows four months ago, but remains in more than three dozen other Windows programs. Moore did not reveal the names of the vulnerable applications or their makers, however. Each affected program will have to be patched separately. Moore first hinted at the widespread bug in a message on Twitter on Wednesday. 'The cat is out of the bag, this issue affects about 40 different apps, including the Windows shell,' he tweeted, then linked to an advisory published by Acros, a Slovenian security firm."

Comments

Re:I Wish I Had the Luxury of Worrying About This.

[0123456]

Then worry about this:

Yeah, I'm far more worried about a _fixed_ exploit that requires I install a malicious GUI app than an active exploit that just requires I open a malicious Word document.

Shared Objects / Dynamically Linked Libraries

[VGPowerlord]

I was under the impression that very few Windows applications were statically compiled... so why can't this just be updated in whatever shared object it uses again?

I know he says

There may be fixes that can be applied at the OS level, but these are likely to break existing applications.

but what and why?

Re:Shared Objects / Dynamically Linked Libraries

[Anonymous Coward]

Because it's an API change.

If you read the linked description, it says that the problem relates to opening files from remote places. With some Win32 API knowledge, you can derive that the problem is:

- DLL loading looks into the process working directory for DLLs (i.e. getcwd())
- Some applications change the working directory to the place where the files they attempt to open reside
- If the malicious actor places a DLL in the same directory as the file to be opened, they can win the race against the application's expected DLL directory loading path.

The fix, then involves either 1) not changing the working directory, or 2) call SetDllDirectory to remove the working directory from the search path, or 3) Use SafeDllSearchMode and make sure the DLL is in one of the places before the working directory.

All of these require changing the application. If you just change the DLL search path (by removing the working directory), applications which expect the old, documented search path might fail to find the DLLs they were looking for (perhaps they explicitly changed the working directory to load the DLL, and wasn't trying to load a remote document in the first place?).

Re:I Wish I Had the Luxury of Worrying About This.

[betterunixthanunix]

The part where an exploit that allows malicious programs to be run without the user's knowledge? Or did you think there were no such exploits?

For the record, I am a Fedora user, not a Windows user. I am willing to acknowledge when there is a security problem. I am glad it was fixed, but that does not imply that it was not a real problem.

Re:I Wish I Had the Luxury of Worrying About This.

[Lunix Nutcase]

Don't run X as root. Who does that these days?

Probably quite a few. Not everyone is running a version of the 2.6 kernel that has KMS.

Re:I Wish I Had the Luxury of Worrying About This.

[mandelbr0t]

Exploitable != Malicious. A system without stack protection is an accident waiting to happen. You should read up on how stack protections eliminate an entire class of exploits, and how subtle exploitable code really is. Even the .NET compiler includes stack protection. I have no idea why Linux has not adopted the use of ProPolice across the board.

My previous response was not a troll; it was based on years of experience running Windows, Linux, Mac and BSD machines. Linux is the most brittle of all of the systems I've used. Even remaining up-to-date from the distro is very little protection, since the underlying problem is not being addressed. Nearly every Linux distro could ship with better security, but SELinux and ProPolice are not enabled by default.

Re:Only 40?

[C0vardeAn0nim0]

makes sense because the native registry/file virtualization is provided by MICROSOFT, and this being slashdot, the mantra is "anything windows does, a third party app does better, because M$ SUCKS!!!", unless it's "shitty iTunes bloatware for windows".

Re:Only 40?

[hairyfeet]

Because what you are calling "registry/file virtualization" has NOTHING to do with security and is simply a hack to allow x86 apps to run on x64? And time and time again we have seen the bad guys blow through Windows security measures since it is the biggest market and therefor offers the biggest rewards? Plus with the Windows 7 version you have no control whatsoever, and I have noticed it really doesn't seem to care what gets dumped in "Program Files(x86) as long as you click yes that first time, Whereas with Comodo I am in control, and I get to say what is allowed and what isn't. And if you'll look up the video reviews posted on Youtube where they try to infect Comodo with malware you'll see time and time again it stop the nasties cold.

Look it is 100% free, has less overhead than every other free AV I've ever tried AND it comes with built in sandboxing. I think the better question is why not use it when there are so many bad guys trying to hack PCs out there? It isn't like 22Mb for an AV AND a firewall is all that much with the multiGb machines of today, so why not add that extra layer of security if it costs nothing?

Re:I Wish I Had the Luxury of Worrying About This.

[fandingo]

Actually, even though Nvidia does not support KMS their drivers do support running X as a normal user. Users of the ATI proprietary drivers are SOL.

Using KMS does not automatically remove the root requirement. For example, Ubuntu uses KMS drivers for many cards currently, but one of the big improvements for 10.10 will be to run X as a normal user with some drivers.