Closed GoogleCodeExporter closed 9 years ago
Original comment by fors...@google.com
on 5 Nov 2014 at 10:05
Additional information based on some further analysis. It seems in part to be
the fault of the Unified Background Process Manager, I've tested on Windows 7
and it doesn't exhibit the behaviour. On 8.1 it goes through the UBPM where as
Win7 doesn't. Another thing is Metasploit have a working exploit for this issue
ready to go
(https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/win
dows/local/s4u_persistence.rb) they presumably don't know it has different
behaviour on Windows 8.1. It looks to be a module to get persistence at the
limited privileges.
Original comment by fors...@google.com
on 11 Nov 2014 at 2:38
Original comment by fors...@google.com
on 28 Nov 2014 at 9:23
Correspondance Date: 16 Jan 2015
< Microsoft have indicates that they do not consider this issue meets the bar
for a security bulletin. It is as expected a UAC bypass which isn't a security
boundary.
Original comment by fors...@google.com
on 16 Jan 2015 at 8:02
While this issue is indeed a UAC bypass it's a regression from Windows 7 and
works even when UAC is set to the highest level. The only mitigation for this
issue is to not run as a split token admin.
Therefore marking as WontFix and removing view restriction.
Original comment by fors...@google.com
on 16 Jan 2015 at 8:05
Is anyone able to clarify why 118 (CVE-2015-0002), a UAC bypass, was
significant enough to get a CVSS score of 7.2, Microsoft to create a bulletin,
and when full disclosure occurred - MS felt it endangered users enough to
publicly complain. Yet this vulnerability (156), also a UAC bypass, gets the
complete opposite response.
Leaving aside the contentious issue of the disclosure process; I can't
understand how this vulnerability is being treated so differently from 118,
when the impact on users appears so similar.
If UAC isn't a security boundary (as Microsoft have long claimed), then I'd
agree that UAC bypasses don't qualify as security vulnerabilities.
Unfortunately, it's hard to see what UAC is; if not a security boundary; and
MS's past response when presented with bypasses (118 included) makes a
compelling case that it is.
Original comment by mountainstormuk
on 17 Jan 2015 at 9:00
@mountainstormuk, Well the difference is 118 was not a UAC bypass, it only used
UAC as demonstration for the proof of concept. This saved time when developing
a suitable PoC to give to Microsoft so that they can best assess the security
implications. As I've noted in the bug report (and others also noted) it was a
more serious EoP than that. I personally have developed a working exploit to
escalate to system privileges from a non-admin user. Microsoft recognized the
distinction between the PoC and the exploitability and fixed it as a security
issue.
In this case the bug is 100% UAC related, if you were not running as a split
token administrator then this attack would not allow you to elevate privileges.
Microsoft have effectively abandoned any hope of fixing UAC to make it a
security boundary so any issue which is related to it (such as integrity
levels, admin approval mode, secure desktop etc.) will only rarely be fixed if
they have an obvious knock on effect or can be accessed from a normal user
account. The fact that this is a regression from Windows 7 just means that it
might be put in the general bug fix queue and _might_ make it in to the next
major version of Windows. I've not tested Windows 10 TP to see if that's the
case. That said if I find issues in UAC I still provide Microsoft a heads up on
the issue in case they either determine it's more serious than I realize or
feel it's easy enough to fix.
As stated, the only mitigation is to not run as a split-token administrator
ever. Perhaps Microsoft should be doing more to ensure people do this, through
education or changes to the install defaults. With this bug split-token admin
on Windows 8.1 Update has zero value from a security perspective.
Thanks,
James.
Original comment by fors...@google.com
on 17 Jan 2015 at 9:23
FYI tested on Win10TP (build 9879) with UAC set to always notify. Elevation of
privlege was successful.
My 2c: You're already an admin, it's not letting you do anything you couldn't
already do, it's just not giving you a heads up (UAC warning).
Good work guys!
Original comment by CraigI...@gmail.com
on 19 Jan 2015 at 4:18
On Win8.1, with "Always Notify" even Task Manager requires a UAC prompt!
Original comment by yuhongba...@hotmail.com
on 18 Feb 2015 at 10:55
Original issue reported on code.google.com by
fors...@google.com
on 5 Nov 2014 at 5:33Attachments: