New vulnerability on Windows XP SP3

I'd wait for the group at MSFN to release a service pack 4. If the unofficial updates and service packs they've released for other operating systems are any indication, the updates will be documented and community tested.

 

You can do whatever you want with an aged obsolete O/S !
Good luck with it. No contest. I would no longer even think of supporting XP.

 

Hmm, I must have missed this thread back then too...

sijaline, please stop spreading MS lies/FUD. Everyone should know by now that XP is supported (though I'm not sure they'll fix these obscure things if they're truly XP-only).

I challenge you or anyone else to show how XP is more vulnerable or "dangerous" than any newer Windows version when updated to the same point in time (which is till now and years more for XP)? Can you accept that challenge?

Yeah Pete, me neither, but for different reasons I guess. Updates are THE most important thing, more than anything else (especially "joke," false-sense-of-"security" software). If there's no vulnerability that even exists, you don't need any other protection...

These closely-related vulnerabilities on exploit-db.com should be easily blockable in Sandboxie (or something else that can block where any risk is, without interfering if you actually need to have the vulnerable part working). I'll investigate and be back with a mitigation solution in the next days.

 

That's because you installed MS08-030, and why I never have. Just by chance in this case (that I didn't have the file added), but I've always checked each update and don't install ones that aren't necessary (on a new, all-relevant-updates-integrated (about 81) XP install, there's just over 30 security updates I've skipped (this is with IE 6)).

Yep... And showing yucky Python. Please actually use C/native code.

Good point. I don't see a driver/service here (I guess it would be called MQAC). I guess I'll try to get it installed on the other system so I can test my mitigation theory...

 

MQAC.sys does not exist on my WinXP SP3 Home.

 

Considering you're a Mod at Wilders, one would think that you would be more current on all things Microsoft than running a tired and weak operating system. All third party support sites for XP have long gone as people have moved on. Some old support site domains are up for sale if you'd like to get one for cheap as I know of a few that are available. Let me know.

Support for Windows XP ended in April of this year. No more Windows Updates means ZERO security. If I was an acquaintance of yours, I would block all your email accounts as they would be transmitted from a potentially infected or easily infected machine.

Although AV Vendors have continued like ESET have committed to extended virus signature definitions (vsd's).
It's time to retire that old junker

I've heard all the arguments anyone could possibly present as this is just a rehash that Windows 98SE users argued after MS pulled extended OS support.

 

An OS does not tire nor does it become weak with the passing of time. It is just a collection of bits

While in principle I agree with you that using an old version of an OS (or other software) can be a security risk, that doesn't mean that you have ZERO security. This is the classical fallacy that if you are not 100% protected that means you are not protected at all. Considering that there is no such thing as "100% secure", and using this flawed reasoning it would mean that security is always zero/impossible to achieve...

 

Yep Nebulus. I go by facts, not FUD/fantasy/fanboy-ism... And the facts are: if Windows XP support had ended (which it hasn't), and when it does, it would have been/will be increasingly more vulnerable as time goes on (I don't know that there's much problem yet if updates haven't been installed since April 8/May 1).

Otherwise, if someone is fine with the outdated "features" part of it, who cares? It's really weird how people harp on stuff just for the sake of it for no valid reason!

Like I said, I don't understand how security people claim XP with the same updates as any later Windows version is somehow insecure or vulnerable, yet they can't give any concrete examples to prove it to us "lowly dummies." Why would it be if the same holes have been fixed?


XP support has not ended siljaline as I'll continue saying (you mean "normal," consumer versions that MS wants to pay to upgrade?) for 5 more years. Isn't it funny how MS could have chosen any name in the world for XP Embedded (and they're good at coming up with dumb names), and yet they called it Windows XP. Why do you think that is? Because it's Windows XP. And you're stating support ended?

LOOK at the file properties of the so-called "Embedded" updates -- it simply says Windows XP [SP3} everywhere, because it's always been the same for the last 5 years. Or wait, are you saying that there's been no updates for XP Embedded the last 5 years and they just started making them now? Perhaps you can ask one of your "contacts at Microsoft?"

You're really starting to sound like a crazy poster, man...

Who cares about AV Vendors in any circumstance? There's no reason for them to exist. Wow, they've committed to extended "VSDs." That's either because "supporting XP" is zero extra work, and/or 2) they want to keep milking money from poor users.


Any Windows 9x was sucking junk, so should have never been used once 2000 was released, which is exactly what we did the week of its release. And updates ended, period, which they haven't now. So this isn't remotely close to a "rehash" of that.

We were off of 2000 just a little before extended support ended (which it actually did), happy? And I thought I might be getting off XP shortly after thinking support was going to end (though I have no clear choice this time), but it hasn't, so that alleviates any worry about the issue, and will allow things to happen naturally over the next years when we hopefully have some better choice(s).

 

I checked an XP Pro virtual machine. MQAC.sys is present in the file system but not installed.

 

Metasploit has an exploit for MQAC.sys.

 

CVE-2014-4971 is the only post-no-more-fixes Windows XP CVE listed here.

 

This seems like the type of vulnerability that, if it applies to you, could be used to bypass Sandboxie, etc. There would have to be another vulnerability exploited or bad code run purposely first though to get bad things started.

 

Fear not, I'll [hopefully] have the mitigation for anything within Sandboxie (dead simple I think) as soon as I get to testing it (along with test program if you don't know if it's accessible/exploitable on your system). Seems like I'll need to install XP Pro quickly to get MQAC...?

 

From http://www.blackviper.com/windows-services/message-queuing/:

 

OK, I'm glad I checked things with Sandboxie! Originally I was just wanting to try opening the vulnerable "file"/object (\\.\BthPan and MQAC) so I could see what we would need to BLOCK within Sandboxie (ClosedFilePath) to mitigate any possible attack (since one of those "things" needs to be opened first).

After my post the other day, I thought wait, maybe we don't need to block anything at all, because the sandboxing/prefixing of stuff in the sandbox would make those "things" inaccessible by default, unless one allowed direct access to them (OpenPipePath).

I just installed the Message Queuing stuff since I couldn't figure out how to get the Bluetooth thing available (I tried installing the BthPan.sys driver manually with Process Hacker and starting it, but there didn't seem to be any BthPan file/object to open). But they're both the same anyway...

I took a line or two of C to try to open the MQAC one then. Yep, opens on real system, AND within Sandboxie (so no prefixing of those objects...? ), unless you block access of course. This actually doesn't matter though, but IF someone wanted to block access in Sandboxie or something else with that capability, here's the "full" names I originally wanted to check:

ClosedFilePath=\Device\BthPan
ClosedFilePath=\Device\MQAC

(You could put that under [GlobalSettings] in Sandboxie.ini.)


But since Sandboxie does allow opening of the objects by default, I wanted to run the PoC exploit to see what would happen. I didn't want to take extra minutes converting the code to native C, so figured I'd just install Python and run the script (wow, what a pathetic language -- copied code complains about indentation (expected) , and then it was still broken anyway, but I fixed).


Anyway, running the exploit on real system? BSOD

Running it Sandboxie? Nothing happens! Even though it can open the initial thing (and says it did everything), it can't succeed. It doesn't matter default settings, or even opening up MQAC for direct access (OpenPipePath), Sandboxie protects. Nice!!


Any other security software I should try to see if it protects??

 

Sounds like SBIE provides copy-on-write access to that resource. It looks like it's there, but input gets round-filed.

Next, hmm. Privatefirewall? Or pretty much any FW/HIPS configured as a policy sandbox. Might work, might not.

(I think the way to do it would be to restrict the Python interpreter executable... Maybe I'll try this when I get home, since it doesn't involve the massive PITA that is Metasploit.)

BTW this is something I noticed a lot of when I last messed around with Metasploit - mandatory access control put the kibosh on a lot of attacks. I wouldn't take that as an indication of real world security though.

 

ALERT: Sandboxie 3.76 does not block the exploit! Dropped rights doesn't help. (Not that I thought it would, this being Elevation of Privilege.) Blocking the device(s) does prevent everything, as expected. Latest 4.13.3 is what I used first, naturally.

Yeah GJ, copy-on-write, but that kind of stuff isn't "stored sandboxed" anywhere, so I didn't know -- although if they're not "real" files with contents (?), maybe there's nothing to store anyway, so just make the HANDLE available. I'm still just surprised it works since I thought it would be prefixed like Sandbox:DefaultBox:\Device\... (Wait, maybe that prefixing only applies to window names, and not file/reg. paths Geez sometimes I'm not even remembering how Sandboxie works. )


If you want to try the Python script and can't get it to work, I'll provide my changed one. (Unless you know Python, unlike me, then easy I guess... )

 

@DR_LaRRY_PEpPeR: any significance to using the old version of Sandboxie?

Re prefixes, is that Windows-speak for namespaces? In that case I'd expect the sandboxed program to be in the same prefix/namespace as the COW device handle, and therfore unable to notice the prefix (or affect anything outside it).

The Python script is rather unsightly, but shouldn't be a problem to get working.

As for Python itself, I shall hold my tongue...

 

@@DR_LaRRY_PEpPeR: So the POC works on XP SP2 under KVM. Runs to completion, and Windows throws a segfault (!) a minute later. Runs as limited user likewise. Okay...

[Edit: unless ctypes methods can fail without raising exceptions? That would be annoying.]

Privatefirewall unfortunately is useless against this; I can't make the restrictions on Python stick for some reason. Requires the user to correctly answer a popup -> instant fail.

 

Microsoft Fixes Critical SChannel & OLE Bugs, But No Patches For XP

 

I'm speechless.

 

From MS14-063 A Potential XP Exploit:

According to http://support.microsoft.com/kb/894199, this was fixed in Windows XP Embedded.

Hat tip: member anon.