Researcher leaks ugly zero-day: Plan for irresponsible disclosure?

A little-known Belgian researcher just dropped a Windows zero-day—a nasty local-privilege-escalation vulnerability.

T. van Houtte, also known as SandboxEscaper, dropped her proof-of-concept onto GitHub this week, without even alerting Microsoft—let alone giving the company time to patch it.

That’s not really what you’d call “responsible” disclosure, but it sounds as if van Houtte has had previous friction with Redmond. In this week’s Security Blogwatch, we’re privileged to escalate, locally.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Chilly Wonka 

Application Security Research Update: The State of App Sec in 2018

Zero-day LPE PoC panic

What’s the craic? Richard Chirgwin notes Privilege escalation exploit, for which no patch exists, dumped on GitHub:

It's not a vulnerability bad enough to force Microsoft to release an out-of-cycle patch – however, CERT/CC has just put out an alert over a newly disclosed privilege escalation bug in Windows. … It's a zero-day with a proof-of-concept.

[This is an] LPE &hellip local privilege escalation – meaning malware or malicious logged-in users can use it to gain control of the system. … It opens an all-too-familiar attack vector: If an attacker can get a target to download and run an app, [LPE] gets the malware out of the normal user context up to, in this case, system privileges. Ouch.

Why not just report the vuln to the vendor? Lucian Armasu speculates—Dissatisfaction With Microsoft’s Bug Bounty Program:

It seems [she] had a bad experience trying to submit either this bug or previous bugs to Microsoft, leading [her] to take to Twitter to publicly disclose it.

SandboxEscaper's behavior is nothing new. Not all of those who find bugs in big companies’ software report them back to the companies. [But] many will still prefer to take the more ethical approach of disclosing the bugs to software vendors.

In a statement … Microsoft implied that a solution may come with the next Update, coming Tuesday, September 11: "Windows has a customer commitment to investigate reported security issues and proactively update impacted devices as soon as possible. Our standard policy is to provide solutions via our current Update Tuesday schedule."

What’s she playing at? T. van Houtte, a.k.a. @SandboxEscaper:

I don't think a job in vuln research is going to happen for me anymore *packs her backpack and wanders off*

I'll be somewhere above the arctic circle, finding comfort in the ice and cold, vuln research is stupid anyways. Bye, bye *waves*

I don't ****ing care about life anymore. Neither do I ever again want to submit to MSFT anyway. **** all of this ****.

Inject into a medium il process ;) doesnt matter which, notepad or something will do.

Enjoy the 0day. It will get patched really fast. I guess I had fun today. Now I'm gone for a while. … Also, this bug and the use of hardlinks are ofcourse inspired by Forshaw.

Can you condone this? Lance R. Vick—@lrvick:

While I can't condone dropping a 0day without an embargo period, I totally get the frustration. You can't make a living in first world countries on bug bounties and companies either don't credit you or take months of badgering to get a reply.
 
At least now you get street cred ;)

But Tim Hampton is less understanding—@TJSpyke:

You didn't tell Microsoft about this, meaning you let users possibly get exploited by this, so **** you.

So how does it work? Kevin Beaumont has this high-level analysis:

It’s a really neat flaw, in particular how it is exploited. … The Task Scheduler API function SchRpcSetSecurity fails to check permissions. So anybody — even a guest — can call it and set file permissions on anything locally.

This exploit misuses SchRpcSetSecurity to alter permissions … to allow a hard link to be created, and then calls a print job using XPS printer … to call the hijack DLL as SYSTEM.

You get a process spawned … called cmd.exe, which spawns connhost.exe, which spawns a random process. This isn’t normal behaviour.

If you use Microsoft Sysmon, look for spoolsv.exe spawning abnormal processes — it’s a sure sign. … Similarly if you use Sysmon, look for conhost.exe (Task Scheduler) spawning under abnormal processes (e.g. the Print Spooler).

But Christopher Hacking takes issue with some of that:

The flaw  … is that the RPC server for SchRpcSetSecurity fails to impersonate the RPC client when changing the DACL of the .job file in %WINDIR%\Tasks. … The RPC server should not attempt to change DACLs without impersonation … that is a serious bug. The RPC server does not need to, and should not ATTEMPT to determine whether the calling process has permissions. … The correct approach is to drop permissions — impersonate the caller — instead.

Creating hardlinks is not, fundamentally, a problem. The hardlink has the same ACL as the target/original. The problem is 100% the being able to change permissions, as SYSTEM, of a file that can be created as an unprivileged user. … You could almost certainly use symlinks with this exploit instead.

And Lee D. thinks It rather involved being on the other side of this airtight hatchway:

For at least the last decade or so I have been led to assume that if you have the capability to execute code locally, then you have the capability to gain administrative privileges. It's really that simple.

I can't imagine there's a secure system in the world (e.g. military, etc.) that thinks it's a good idea to let a user run arbitrary code in any instance. … Even then you can be compromised (e.g. escaping a web-browser sandbox, etc.).

The expectation for arbitrary code execution for anyone other than an administrator … or developer … is something that I can't justify.

Speaking of “irresponsible” disclosure, Here’s Leo Kelion, with Google is irresponsible claims Fortnite's chief in bug row:

On Friday, Google made public that hackers could hijack the game's installation software to load malware. … Epic's chief executive said Google should have delayed sharing the news.

A spokesman for Google declined to comment.

Google has been criticised in the past by Microsoft for sharing details of vulnerabilities in the Windows-maker's products before they had been addressed. [Google] has also caught out Apple and Samsung in a similar manner.

[But] Google's disclosure rules state that it reveals details of bugs to the public 90 days after reporting them … if they have not been tackled, but only waits one week after a patch is made "broadly available".

Meanwhile, Scott Helme waxes excoriating:

Google followed standard responsible disclosure guidelines and didn't release any details until a patch was available. Attacking Google now only makes Epic look worse.

Suggesting the work of those responsibly disclosing critical security issues is anything to do with PR shows a complete lack of respect for the researchers. … If only Epic had a reliable way to get users to update software quickly ¯\_(ツ)_/¯

"Hey we screwed up big and we want special treatment", it's just not how this works. … What Tim seems to be missing is researchers like us act in the best interest of those affected and the negative PR for Epic doesn't factor into that. 7 days after the patch has gone out, those who are going to update quickly have done so. Then it goes public to drive updates.

Epic … got free research, support and a heads up, and here they are complaining and trying to point fingers!! … Pro Tip: If you don't like the way that 3rd parties handle responsible disclosures with your company, don't ship products with critical security vulnerabilities.

The moral of the story? Expect occasional irresponsible disclosure, but “patch+7” is not an irresponsible timeline.

And finally …

Chilly Wonka


You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hatmail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.

Image source: Daniel Cortes (cc:by-sa)

Topics: Security