Windows 10 Privilege Escalation via Dolby's DAX2_API Service | Hacker News Reader

Windows 10 Privilege Escalation via Dolby's DAX2_API Service

x42.obscurechannel.com

88 pointsx4223 comments

"System" is the highest privilege, like "root" on Linux.

Not necessarily in Windows 10 Enterprise, there can be some limits to what "System" can access, with a feature designed to protect credentials from exploited drivers:

With Windows 10 and Device Guard, credentials are stored encrypted using Hyper-V, an approach known as "virtualization-assisted security." Credential Guard blocks access "even when an untrusted program has full administrative access to your environment,"

Drivers can't get into the Local Security Authority of Windows 10

https://redmondmag.com/articles/2015/10/28/windows-10-creden...

So, System still has full access to ring 0, but some bits of the OS are moved into the hypervisor "ring -1"?

It seems a bit more inception-like than your numerics betray... The driver ring 0 is now a deeper dream than hypervisor ring 0.

You can limit root on linux too with a MAC framework.

So it's not even a vulnerability in the service's code, but in its metadata (file permissions).

Neat!

ships with Lenovo Thinkpads running windows 10 by default, possibly windows 8.

I can imagine it would be possible to reverse engineer the service interfaces of DolbyDAX2API.exe ("exported functions"), write a wrapper which embeds the original executable and forwards the service requests to the original implemententation. The wrapper could contain malicious code and intercept the service calls. This could be even done generically. Maybe something like this exists already anyway. This way nobody would notice that something is wrong - functionality wise. Perfect eavesdropping on Windows services.

I was thinking this was where the article was going, but the solution ended up being a lot simpler. It leaves traces and notifies the user, though...

I suppose yet another way would be to make a copy of the executable before the overwrite, then restore it after gaining a stable SYSTEM shell.

Is this "Dolby DAX2" a standard component? There's no trace of it on my stock Windows 10 Surface Book.

Nope. It's some crapware that IBM bundles.

IBM's not had anything to do with ThinkPads for a decade, and hasn't had any presence in even x86 servers since 2014.

Lenovo outsourced support and maintenance of both to IBM for various markets, but that's as far as it gets.

No, it is one of those OEM enhancements that get delivered with nice sound speakers.

Let me rephrase that: "with crap speakers to make them seem less crap".

My Dell laptop has "MAXXAUDIO PRO", which does a bunch of heavy-handed stuff to make audio sound "better." I finally found the program when I was trying to figure out why my audio levels seemed to change.. My music would get louder over time, and if I moved the volume one increment up or down, it would drop back to the normal level. Turning off the sound-mangler solved that issue and allowed my music to sound the way it's supposed to.

It really frustrates me when manufacturers include crap like that.

Yes! This is why I was thrilled when Microsoft started making their own laptops. The only thing I had to kill on this Surface Book was this annoying little popop that offered deals on Microsoft Office, and that was simple to disable--it had an uninstall button right on it.

its value added BS. Dolby tries very hard to be Creative 2.0 by pushing patented crap into standards (hdmi, bluray) to position itself as essential for hi def audio = collect patent tax.

The ubiquity of DTS in the PC and hifi market is probably scaring the crap out of them.

This is really an argument about whether or not proprietary systems are inherently more secure. I run Arch on my main system, and when a vulnerability is disclosed, it's often patched within hours. Windows is littered with bugs, vulnerabilities, and security holes. Older versions have been left to rot, leaving thousands of systems vulnerable.

Of course, it could be argued that the weakest link in the chain is the user, but with a vulnerability like this one, I don't see how that applies.

In this case the "user" is the system manufacturer who developed an exploitable application, in this case, Lenovo.

Lenovo could sell a Linux PC with a similar application that communicated with a daemon running as root which binary was saved in /bin with 0777 permissions.

There is nothing special about Windows that makes this vulnerability possible.

The end user mistake here was buying Lenovo.

For things like this SELinux really comes in handy.

I really don't understand your argument here.

As per definition of vulnerability, this is something that many Linux systems have ran into in the past. When you get outside of mainline distributed programs you see vendor issues like this all the time. 777 is a thing in Linux and people/vendors do dumb crap with it all the time. Privilege escalation to root via bad file permissions is not an uncommon problem in Linux either.

The patch for this problem is easy enough too.

Right click > security > remove full access.

If this application is widely distributed enough Microsoft may very well push a fix for it. What we don't know here is how many computers are affected by this, it could be a very large number, or it could be a few from a limited distribution with a bad setting.

Reply on news.ycombinator.com