Hacker News Reader

Comment by deweller | Hacker News Reader

> Lee was able to take down both stable and beta versions of Chrome by exploiting a buffer overflow race condition in the browser. He then used an info leak and race condition in two Windows kernel drivers to secure SYSTEM access.

I'm trying to fully understand. Does this mean that by maliciously crafting a website, someone can get SYSTEM access on a windows machine just by getting someone to visit that site in Chrome?

And what does SYSTEM access mean? Is that user-level privileges or admin privileges?

View on HN

That's correct. The best paying exploits at Pwn2Own are exploits where just browsing to a website gives an attacker root code execution on the machine.

These types of exploits pay well because they are extremely difficult to pull off, as they require multiple exploits to break through the browser security, out of the sandbox, and through the OS protections.

And yet every year they have been found. It's safe to assume browsing to a site can take over your entire machine at any time. Enjoy the web guys!

The regrettable truth is that this pushes us all toward a more centralized web, as it's much less likely that google.com or facebook.com is going to pwn your browser.

The real nightmare scenario is when developer machines get hacked and attackers get access to source, but also to build servers where they can inject binaries into the web deployment stream, which themselves exploit end-user browsers. This is, I think, a very good reason to not give devs any access to build/CI servers. (Ironically, actual endpoint servers are slightly less critical to secure from devs.)

The lovely choice:

1. facebook where the NSA are checking on you

2. faceskibook where a Russian hacker is going to own your pc

The few times I've caught on-load viruses was when visiting big sites. Turns out their ad networks often get compromised and suddenly reddit or facebook are loading exploits.

Virtualizing and sandboxing the browser in a secure way is the only way out of this. On top of an eventual move to memory safe languages.

That's a damn good point. It also means that ad networks and CDNs are the best targets.

True it is a scary web but how many of those exploits have relied on default settings and Javascript to run?

You are many times safer on the web if you have the discipline to use noscript properly.

Fun fact: Noscript loads and parses all javascript and then just stops it from running against the live DOM. Decreases page render time, sure. Prevents exploits? Don't think so.

I can't recall a single exploitable bug in these competitions that attacked the javascript parser. Running the js is a far larger surface area to attack.

NoScript won't actually execute any of the Javascript, though. I am not aware of any historical vulnerabilities from the mere act of loading and parsing Javascript, though they're certainly theoretically possible. It's much easier to secure a parser than a runtime.

That does not affect security significantly. If it did then it would totally defeat the purpose of noscript existing.

> True it is a scary web but how many of those exploits have relied on default settings and Javascript to run?

Layout (just to name one non-JS subsystem) has been responsible for a lot of vulnerabilities too.

True, but from experience it is often the case that exploits are obfuscated by being wrapped in one or more layers of JS, so that they are less likely to be discovered by passive scanners.

This will probably seem quite shocking, but I almost exclusively used IE6 for a few years, with JS disabled - and despite frequently visiting the "darkest corners" of the Internet, was never exploited. On the sites that tried, I'd just see a blank page; view the source, and there was a blob of obfuscated JS.

And if the person sitting next to you in the same organization doesn't do that, or any person doesn't do that, if they get compromised then their box could attack yours with a different kind of payload.

And that is why you browse with a virtual machine which is re-initialized from the CD copy every time you restart :-)

.. running inside another virtual machine just to be secure from guest-to-host escape vulnerabilities.

Repeat as many times as necessary based on your paranoia levels. Inception.

And nesting of virtual machines is still useless if you have bugs in CPU like this (2012):

http://www.kb.cert.org/vuls/id/649219

And then you add a hardware emulator!

That only applied to Xen's paravirtualization mode (runnning a modified guest OS as an unprivileged process), not the hardware-assisted virtualization.

So for a long time I had a spare Vax (MicroVAX III if you're wondering) hooked up to a modem on an unused phone line (yes it answered as KREMVAX), and when sufficient internet bandwidth came along put it on the Internet to watch people "hack" it. It was fun because they would get all confused when their x86 exploit code wasn't even a thing :-).

But your comment reminded me that if I ran a virtual VAX and then a virtual Windows on top of that and a browser in the windows, breaking out of the 'guest' into VMS would really challenge the bad guys tool box in terms of zero days :-) Fun to contemplate on a Friday afternoon.

VMCeption

On the slightly less dark side, we can probably assume that this class of exploits is so valuable that nobody would use it against a large number of people at once in an ordinary way, like sending out spam emails or comments with links to build a botnet. That would likely result in it getting noticed and patched quickly, for very little return on investment.

These types of exploits are probably only used by very well financed organizations in carefully targeted ways, so as to justify the huge cost of finding them and keep them unnoticed and unpatched for as long as possible. See the recent stories on the Equation group-associated malware. You and I are probably safe enough, but somebody like Edward Snowden better be very careful where he surfs.

I've never thought about surfing in a VM before, but it seems that if you're ultra paranoid that it would be best to do so.

Starting to think that running apps within a container is the right way to go.

Qubes tries to build the OS that way.

https://www.qubes-os.org/

Or on a completely separate machine: Exploits have been found for visualization software. Of course, then you need to be concerned about the network and so on.

It's turtles all the way down.

That's why I have a separate machine which I use just for browsing the Web, which I keep disconnected from the Internet in a sealed steel box.

...

Unplugged from the mains.

IMHO, the bigger concern is the exploits that the wider community hasn't found yet. How many nasty tricks were out there in Stuxnet for years before anybody noticed? Just given the scale of the stuff that's been found, I'm inclined to think that trying to out-secure organizations with that kind of resources is a losing battle.

You're better of not being somebody anyone would invest that kind of effort to hack. Or at least making your traffic not identifiable as somebody that your opponent would want to hack.

Last I checked, holders of large amounts of Bitcoin tend to avoid letting their identity be associated with their accounts easily, and that's probably why. I bet somebody would be willing to risk a few $100k exploits to get a few $million worth of BTC.

See Sandboxie

> Starting to think that running apps within a container is the right way to go.

If you're talking about something like Linux containers, note that the Chrome Pwn2Own exploit involved a sandbox escape via a kernel exploit. (Though seccomp-BPF mitigates this to some extent on Linux.)

Any yet every time JavaScript blocking extensions are mentioned, it gets ridiculed.

edit: case in point, someone posted about it right before and it's downvoted. Good job!

Welcome to Hacker News in 2015, where the community mindset has changed from the old school Slashdot's reverence for software freedom and ideology to modern Reddit's mantra of "Who cares? It works! Get real!"

1) >implying the mindset on HN hasn't always been "push things and break shit who cares"

2) /r/programming and other software development subreddits are actually closer to slashdot's ideologies (excepting /r/webdev where performance is an overrated thing)

The good news is that HN seems to be slowly going back to a more old school mindset. At least you can criticize javascript.framework.of.the.day.js without being showered in downvotes, as opposed to a year ago.

Not exactly - the economics are important.

Anyone who builds an exploit like this is not going to waste it. It's either going to be used in targeted attacks, or reserved for pwn2own. They're not going to burn it by leaving it on some hacked site to get used on your grandmother.

Those types of attacks happen after the exploit is already known and has patches available. The good stuff trickles down, and the early days of active exploitation are more or less restricted to those with the deep pockets and legal impunity.

Most (not all, but most) of these exploits cannot run if you use NoScript/NotScripts or equivalent.

And not a single modern website will run either. If you're willing to disable javascript in 2015, you might as well not use Internet at all.

Yes, which is why NoScript allows fine-grained controls. It's not a straight up disabling of Javascript.

You whitelist the sites you trust. Then if any of those sites get hacked, there will likely be a line added like <iframe src="http://evil.com/exploit.html">, or <script src="http://evil.com/exploit.js"></script>. NoScript will always prevent those since whitelists are domain-specific. So unless the malicious Javascript is added 100% inline on the compromised site (which is easy to do, but is done less often for a variety of reasons), you're going to be safe.

And, obviously, you do not whitelist random sites you click off of Google searches or from emails without validation.

So, most sites won't work, and the ones that do work will still be vulnerable? Awesome.

They're vulnerable if you whitelist them and they get hacked and exploit code is sent directly in the HTTP response. Just like how HTTPS (and HSTS and certificate pinning) does nothing for you if the server is compromised.

If you're careful about what you whitelist, NoScript adds a lot of additional security.

It definitely improves security, but you'll still be screwed against a targeted attack against a specific website.

The attack against Forbes.com is a good example. That is a site you would have whitelisted and the attackers compromised that website to then elevate access to the people browsing that site (government employees specifically targeted).

http://www.forbes.com/sites/thomasbrewster/2015/02/10/forbes...

I work in incident response and actually investigated that watering hole firsthand at our organization. The SWF was hosted on a separate domain, so NoScript in fact would have prevented that specific attack from working even if you whitelisted forbes.com.

NoScript will very often block exploit chains from occurring even if it won't necessarily always block stage 1.

That seems pretty hyperbolic. There are plenty of reasons to not use javascript.

Then perhaps the problem is with "modern" sites superfluously using JS. The majority of sites that I've come across from casual browsing (usually via Google search) don't need it to display the content I'm looking for, and when I do find one that does and Google's cached version doesn't contain what I'm looking for, it's almost certain that I'll just move on to the next search result.

Another trick to try: If you use Firefox, then often you can see the contents of a site by View -> Page Style -> No Style.

Other than that, I agree with you. I never enable JS for a random site, I also "move on to the next search result".

Saying that using NoScript means disabling Javascript wholesale is like saying using SELinux or AppArmor means disabling filesystem access wholesale.

It's a disingenuous and silly argument.

Enough of the internet works for me with `javascript.enabled` set to false.

> And not a single modern website will run either.

I find that the vast majority of websites run perfectly fine with NoScript. What exactly qualifies as a modern website?

Even if they do "require" JS, you can enable one or two of the scripts that are actually necessary and keep the 22 ad/tracking/various-other-third-party scripts disabled to minimize the attack surface.

I have JS turned off due to paranoia. And surprisingly, most web sites Do work without it! I also do not miss all the ads and other annoying stuff.

Even budget servers now a day can handle thousands of requests per second, so there is no benefit in offloading "server stuff" to the browser client.

I do have to add some sites to the white list though.

Perhaps HN isn't "modern" but it runs great w/o Javascript.

For me, the big win of things like NoScript is that I can block the zillion websites OTHER than the one I'm actually trying to view. This has the upside of making my web browsing amazingly fast because it stops the 50 DNS queries that every page makes.

Forbes.com is mentioned, here's what else is on that web page after enabling forbes.com:

Blacklisted: doubleclick.net, optimizely.com, bluekai.com, scorecardresearch.com, googletagmanager.com

Other: forbesimg.com, gigya.com, sail-horizon.com, amazon-adsystem.com, media.net, garble.cloudfront.net, chartbeat.com, mediavoice.com, .............

Do YOU trust that ALL of those sites got their Javascript secure? BWHAHAHAHAHAHAHAHAHAHA!

And, let's not even start with all the people who run "Blogoblather 0.4.5" (it will never reach 1.0) who could just post a static web page. No, I don't want to discuss this, and no I'm not logging in. Oh, and, gee, if it were a static web page, if you do get featured on Reddit, YOUR SERVER WON'T FALL OVER AND DIE accessing a database that doesn't have any comments other than spam anyway.

I run NoScript. Most websites are just fine.

That's a bit of a defeatist attitude. I prefer to believe that bad decisions about our civilization's communications infrastructure can be reversed.

This particular exploit relies on Native Client, which is concerning since it is on by default and is hard to disable.

Hard to disable? Just open chrome://flags and click Disable under Native Client.

And how many people know of Native Client, let alone about chrome://flags? Not to mention that advice won't work then not using a persistent Chrome profile. And Google removed "--disable-plugins" so it is not even possible to automate disabling these plugins short of recompiling Chromium.

You have some point, but how many people even know what Native Client is? Or even JavaScript?

As a sysadmin, I find these exploits deeply disturbing. It used to be that people actually needed to download a file and, like, execute/open it for their systems to become infected.

Recently, my users have been hit by fake DHL/UPS "track your shipment" mails, and some of them were sufficiently un-paranoid to click on the links provided by the mails, which apparently just showed a generic-looking 404-page.

Which might mean that the offending page had already been taken down. But on the other hand, with these exploits, that can already be enough to infect an unsuspecting visitor.

Well, one more reason to use Dillo, I guess.

It's never been the case that people actually needed to download a file and open it to get infected. Actually, in some ways things have improved - it used to be a lot easier to find this kind of exploit, which is why there weren't rewards like this for finding one.

SYSTEM is roughly equivalent to root on linux.

My interpretation of the article is that he managed to escalate far enough to get into the kernel, allowing him to to modify some data structure to give a user land process higher privileges.

So, the overall process could be something like Chrome escape => windows driver vuln => full control of the system.

SYSTEM is admin privilege internal account, IIRC. It's a user on windows - http://i.imgur.com/MkP9pIm.png

> someone can get SYSTEM access on a windows machine just by getting someone to visit that site in Chrome?

Or, I believe, through any of the other Windows browsers. There was nothing Chrome specific about getting SYSTEM access.

All browsers were pwned, and Lee used kernel driver bugs to elevate privileges. That exploit could have been used in tandem with any of the browser exploits on Windows. Once you can run arbitrary code...

IIRC on Windows, SYSTEM is an account something less than full Administrator but more privileged than a normal user. I think many services run as SYSTEM.

SYSTEM is root.

SYSTEM is arguably not a user, because a user has things like a password, groups, and other user properties. SYSTEM on the other hand is a built in low level security context which cannot be removed, altered, or shared across a network. You cannot login as SYSTEM, but processes can run as SYSTEM. It has a static SID on all Windows systems as S-1-5.

Some of the processes that run as SYSTEM in SYSTEM: ntoskml (Windows Kernel), all drivers, and all interrupt handlers. A few key services (not all, and fewer every release).

Literally it doesn't get higher than NT AUTHORITY\SYSTEM on Windows. The administrator account no longer exists on most Windows installations at all, and the administrators group is just that, a group.

It is like root on UNIX, if the root account had been configured to disable interactive login and to allow sudo only.

PS - SYSTEM is sometimes called NT AUTHORITY in documentation. I've seen it called both, I've also seen it called "NT AUTHORITY\SYSTEM." I believe the NT AUTHORITY is referring to the lowest level of permissions within the OS, and SYSTEM is at that level/root of the permissions table. So really NT AUTHORITY and SYSTEM are equivalent.

It is like root on UNIX, if the root account had been configured to disable interactive login and to allow sudo only.

Which is what Ubuntu actually does :)

https://help.ubuntu.com/community/RootSudo

Thanks for this explanation! :)

Small nit:

S-1-5-18 is the SID+RID for "NT AUTHORITY\SYSTEM". S-1-5 is just the "NT AUTHORITY" prefix.

Another small nit: Every Windows installation has two built-in accounts that can't be removed (but can be renamed!): Administrator and Guest. It's just that they're both disabled by default (since Vista I believe) and there's no easy GUI to enable Administrator while there is for Guest.

When I configure a service that runs as SYSTEM user, I cannot perform administrative calls on that service. For example, a powershell script fails with "access denied" when it has an operation that requires admin rights. So I think, running as SYSTEM does not make you root all the time? Or am I missing something?

You cannot login as SYSTEM, but processes can run as SYSTEM

There's a trick to do this, I only remember it well for XP (via task scheduler/at command) but it's possible for the newer versions too.

In Windows, Administrator is not the true root.

Use psexec: https://technet.microsoft.com/en-us/sysinternals/bb897553.as...

It's occasionally useful to run regedit as SYSTEM.

That's not logging in as SYSTEM, that's running an explorer process as SYSTEM.

Another way to accomplish it in XP & such was by copying cmd.exe over one of the default screensavers (which are also just regular programs). When you're at the login screen the screensaver gets run as system, thus giving you the equivalent of a root shell. Launching explorer from it would result in a new user profile being created in explorer and you'd be "logged in" as SYSTEM, but not really.

Nope, it is MORE privileged than full Administrator!

You might think so, but check the service configuration (services.msc) - on a typical Windows machine, you will find plenty of services running as SYSTEM. Basically, nearly all services that do not need to face the network (Windows has another builtin account for that, which I think is called NETWORK or NETWORK SERVICE on English versions of Windows).

Reply on news.ycombinator.com