
Down the Rabbit-Hole - janvdberg
https://googleprojectzero.blogspot.com/2019/08/down-rabbit-hole.html
======
Aissen
It looks like it's yet another missed deadline for Microsoft ?

[https://bugs.chromium.org/p/project-
zero/issues/detail?id=18...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1859)

 _Edit:_ it's unclear:
[https://twitter.com/taviso/status/1161297483139407873](https://twitter.com/taviso/status/1161297483139407873)

I'm not surprised, seeing how deep this reaches and the scope of the issues.

And the toolset Tavis used is also released (linked in the blog):

[https://github.com/taviso/ctftool](https://github.com/taviso/ctftool)

~~~
zawerf
I find the culture around 90-day disclosure deadline fascinating.

Is it actually reasonable to disclose this just for missing the deadline given
that it has already been exploitable for twenty years? I know nothing about
security but I just feel so bad for people who have to scramble to fix this
legacy system which they probably had nothing to do with. I don't think I have
ever seen a good secure system understood, redesigned and reimplemented in
less than a quarter. The exploit author himself seems to have spent months on
this without coming up with a fix either.

~~~
gwern
First, you need a hard bright line as a norm. It's the only thing a
corporation will understand, and you can see how often they try to abuse or
delay it anyway. Disclosing after the deadline is the only thing that gives
the deadlines urgency and means that things which _are_ urgent also get
handled quickly. If there isn't a working process for handling as serious a
vulnerability as this within 90 days, then there probably isn't a working
process for handling serious but time-sensitive vulnerabilities within 90 days
either. Use it or lose it.

Second, these things are a lot more correlated than you think. Look at Spectre
recently: those bugs have been in there in various ways for what, 20+ years?
Yet something like 3 different research groups all came across variants of it
simultaneously. There are pervasive correlations leading to
[https://en.wikipedia.org/wiki/Multiple_discovery](https://en.wikipedia.org/wiki/Multiple_discovery)
\- people use similar tools like fuzzers, they follow similar research topics
and gossip, certain things become 'obvious' to everyone simultaneously, and so
on. OP might not think that anyone else is working along similar lines, but
how could they know that? How should anyone interested in Spectre have known
that there were (at least) that many other groups finding similar problems?

------
vardump
Crazy. So any process can use MSCTF (Text Services Framework) to elevate
itself into NT AUTHORITY\SYSTEM through UAC prompts or logon screen, because
Microsoft forgot to implement access control!

I wonder whether this can also be used to escape sandboxes, but don't have
time right now to analyze that. If so, this will be even more dangerous.

Edit: Yup, can be used for sandbox (AppContainer) escapes. The blog post
mentions it, just didn't notice at first scan.

While I respect Google's security team's 90 day vendor response policy in
general, I think it is too reckless in this case. This can too easily escalate
previous "harmless" contained sandbox compromises into full system wide ones.
A lot of people are potentially now on the harm's way.

~~~
excalibur
Agreed. This isn't a simple patch, and will require significant re-engineering
of a critical Windows component. 90 days is entirely unreasonable in this
case. Releasing his ctftool was particularly reckless, this is privilege
escalation in a bottle.

~~~
techntoke
Reckless by Microsoft or the researcher? Cause we don't know who has been
exploiting this already and by providing the tool adds pressure on Microsoft
to expedite this and helps people that may have already been effected have
some insight into how they were compromised.

~~~
zelon88
The righteousness of your post reminds me of the climax of a Disney movie.

Google does this all the time, on purpose, like clockwork. They aren't the
only ones out there looking for zero days in their supply chain, but they're
the only ones who ignore a vendors disclosure policy and substitute their own.

For example; If Google finds a bug in your product _YOU_ get 90 days before
they put you on blast in front of 8 billion people.

But if you find a bug in _GOOGLE 'S_ product and put them on blast _YOU_ will
find yourself in court.

Does anyone remember the last time Microsoft or Apple went looking for zero
days to drop in public on their blog about Google? They don't. Because they're
professional companies with better shit to do than stir the pot.

This has _NOTHING_ to do wit supply chain security and _EVERYTHING_ to do with
putting heat on their competition. That is why PZ exists. If that weren't true
PZ would be looking at non-competing products with large user bases. WordPress
comes to mind. But Google doesn't compete with WordPress, so they'll never
focus on it.

~~~
temac
> For example; If Google finds a bug in your product YOU get 90 days before
> they put you on blast in front of 8 billion people.

> But if you find a bug in GOOGLE'S product and put them on blast YOU will
> find yourself in court.

Reference needed.

~~~
zelon88
> For example; If Google finds a bug in your product YOU get 90 days before
> they put you on blast in front of 8 billion people.

[https://www.vice.com/en_us/article/7xqdxe/google-project-
zer...](https://www.vice.com/en_us/article/7xqdxe/google-project-zero-hacker-
iphone-bug-bounty)

[https://www.csoonline.com/article/2867534/microsoft-
blasts-g...](https://www.csoonline.com/article/2867534/microsoft-blasts-
google-for-vulnerability-disclosure-policy.html)

Here are Google's many contradictory policies about disclosure. Notice the
many discrepancies...

[https://googleprojectzero.blogspot.com/p/vulnerability-
discl...](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-
faq.html)

[https://security.googleblog.com/2010/07/rebooting-
responsibl...](https://security.googleblog.com/2010/07/rebooting-responsible-
disclosure-focus.html)

[https://sites.google.com/site/bughunteruniversity/nonvuln](https://sites.google.com/site/bughunteruniversity/nonvuln)

[https://www.google.com/about/appsecurity/reward-
program/](https://www.google.com/about/appsecurity/reward-program/)

[https://www.google.com/about/appsecurity/](https://www.google.com/about/appsecurity/)

[https://googleprojectzero.blogspot.com/p/vulnerability-
discl...](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-
faq.html)

> But if you find a bug in GOOGLE'S product and put them on blast YOU will
> find yourself in court.

Maybe a bit of a dramatization, but the point remains. If Google finds a bug
in your product: Your policy is moot. They follow their policy. If you find a
bug in their product you are expected to follow their policy.

In the case of Apple their "security professionals" will make jokes about you
on Twitter and in the case of Microsoft they just do whatever the fuck they
want. "Your patches come out on Tuesday, huh? Well that's 92 days, big-guy!
Tough break..."

~~~
a1369209993
> If you find a bug in their product you are expected to follow their policy.

Is their policy more than 90 days? Yes? Fuck 'em; post everything everywhere.

~~~
icebraining
It's not; from parent's own links: "We of course expect to be held to the same
standards ourselves."

~~~
fencepost
* impolitecough *

Great, then they should start pushing OS security patches out to devices
instead of handing them to manufacturers and carriers and washing their hands
of them.

~~~
hansjorg
They have started that. That's why more and more of Android has been moved to
Google Play Services.

Coincidentally, that's one of the reasons why being denied use of Android is
such an obstacle for Huawei, even though it's "open source".

------
zamalek
> (GitHub) There are some requirements for this attack to work, as far as I'm
> aware it will only work if you have a display language installed that uses
> an OoP TIP

There is an IME installed on every Windows 10 installation for at least a
year: the emoji IME. You hit WIN + . to invoke it. I'm not sure if it's a OoP
TIP.

------
SmileyRedBall
2002 is calling and wants it's shatter attack back.

“Shatter Attacks - How to break Windows.”

[https://web.archive.org/web/20060904080018/http://security.t...](https://web.archive.org/web/20060904080018/http://security.tombom.co.uk/shatter.html)

~~~
deckar01
That exploit seems limited to applications that are designed to execute
arbitrary commands based on user input (consoles). This exploit goes a step
further and finds vulnerabilities in the CTF protocol's implementation so that
any process's privileges can be hijacked to run arbitrary code.

~~~
temac
IIRC shatter attack was exploiting a badly designed general purpose window
message protocol that by design quasi-directly allowed arbitrary code
execution (especially at the time, with no mitigation).

This one is way more indirect and goes through obscure and less reviewed
channels, but the end result is kind of the same, even worse; because the
integrity level was supposed to fix that mess, except MS was not lying when
they said that this was not a security boundary... only they did explain the
full picture properly explain so that we could understand that UAC is _this_
much worthless -- lots of people thought of it as reasonable enough when set
on Always notify, turns out it seems just plainly broken -- and because there
seems to be no proper design _comprehensively focused_ on that topic, it is
very possible that there are other avenues to achieve the same result.

I think I now understand way better why they want so much (and have started
since some years) to leverage virtualization for security purposes: it seems
impossible for them to evolve their historical crappy design to something
sound (without breaking all kind of crazy 3rd party applications) otherwise.

------
saagarjha
> the kernel is creating a new window on behalf of a process

> The kernel forces applications to connect to the ctfmon service when they
> start

> the kernel invokes a callback

> the kernel still forces AppContainer processes to join the ctf session

I know next-to-nothing about Windows's architecture, but why does the kernel
do all of these things? Seems like something a more purpose-built process
should do?

(Aside: my browser does not allow for loading Consolas, and the code snippets
don't have a fallback to monospace so they render in a serif font. It'd be
nice if they didn't do this.)

~~~
repolfx
It's called Windows for a reason ;)

Even in Windows 10, the Windows kernel does a LOT of stuff that's GUI centric.
Indeed the entire Windows API is totally GUI centric. The fundamental IPC
primitive is window messages, which is a microkernel-esque very fast inter-
thread/process context switch tool. Like in seL4 or similar you get to send
two numbers this way and not more, and it's optimised heavily. Other IPC
systems you'd expect to be GUI independent like DCOM end up using this under
the hood.

It used to be that the entire GUI subsystem ran in kernel mode, because
context switching was very slow and it made a big difference. In Vista+ large
parts of it moved out into a separate privileged process, but the kernel is
still involved in IPC, I believe. So when Tavis says "the kernel is creating a
new window on behalf of the process" that's not quite correct, I think.
Various subsystems get involved in creating windows and mostly not running in
kernel mode anymore.

~~~
kyberias
> Indeed the entire Windows API is totally GUI centric.

I think this is fundamentally incorrect. Windows certainly allows processes
and threads to exist with no GUI. The process doesn't need to have message
loop, etc.

I suggest you check your other facts as well. Windows Internals is a good book
to start.

~~~
temac
You are technically correct about processes not _absolutely needing_ to use
graphical resources.

But the whole thing is nevertheless backed in and coupled with low layers,
including the kernel. There is just a kind of lazy init of GDI resources and
the like so that the init is skipped for those processes which don't use them
ever. It is fundamentally different from a general purpose OS like Linux which
does not care _that much_ (or even at all? I haven't checked) about graphic
shits for processes.

~~~
kyberias
Your assessment is wildly inaccurate. Windows NT is a general purpose OS like
Linux and the lower layers really don't know or care about the GUI.

The Windows NT kernel has been carefully designed like that from the start. In
fact, the Windows part of NT is called a Windows subsystem. Windows kernel
DOES NOT do windowing. The Executive, Kernel, Device drivers and the HAL are
cleanly separated.

In fact, Microsoft provides Windows Nano Server which is a totally headless
installation with no GUI components.

~~~
temac
You are talking about _mostly_ source code organization. Which every sane
project does.

So of course it is unlikely there is something that e.g. draws pixels in the
scheduler.

But for example there is still some space reserved in the TEB for GDI things.
And kernel space code for graphic purposes _related to processes and threads_
\-- a kind of graphic "kernel" if you want. I mean: you just cannot take
Windows and change all the low level graphics support code to a kind of
WinWayland or WinAndroid. Even just programming raw NT processes is not
officially supported IIUC, so you are bound to using e.g. Win32, and there
definitively are some pieces of code all over Win32 (and not _just_ in
trivially graphic related APIs) which is aware of the existence of graphics
related features on the OS.

So while it might be possible to recompile and/or rewrite parts of NT if you
work at Microsoft to actually obtain a graphic agnostic OS (which is not even
_exactly_ what Nano Server is despite the re-engineering effort, because it is
explicitly graphicless, not just graphic agnostic, and actually it now does
not even exist anymore in a standalone form but only for containers, so you
stick with your regular host kernel), that's not what I had in mind.

------
typeformer
Thank you team Project Zero, certainly my favorite team inside Google.

------
jmartinpetersen
"I decided it would be worth it to spend a couple of weeks reverse engineering
CTF to understand the security properties."

Just, wow, that he gets to spend a couple of weeks on stuff like that.

~~~
PeCaN
As someone who occasionally reverse engineers things for fun, the fact that he
managed to completely RE the whole thing to such a high level of detail in
only a couple weeks is mind boggling.

~~~
mkl
I think that was his initial idea, but he kept going when he found stuff. From
later in the article: "This was a bigger job than I had anticipated, and after
a few weeks [...]".

------
lowdose
Google just buried Windows. Google came in with what seemed to be a
spectacular bouquet of flowers, but left a cactus in MS rear end. This is how
Taviso 63 days earlier was being treated by Microsoft.

> They called me and _told me my career would be destroyed._ In one
> particularly memorable call they told me that their PR and legal department
> only had two settings, "off and destroy" and (in a rather menacing tone)
> that they would "air my dirty laundry in public".

[https://news.ycombinator.com/item?id=20171450](https://news.ycombinator.com/item?id=20171450)

This is such an Easter Egg they should send some Bunny suits to those clowns
at Microsoft HQ.

~~~
bbernoulli
Maybe I misunderstand your comment, but @taviso was recalling a story that
seems to be from 2010.

~~~
lowdose
Sounds like the ultimate payback for behavior in 2010 which violated all code
of ethics.

------
dirtylowprofile
Any response from Microsoft?

------
lisper
Clickbait title. Should be: tracking down an obscure Windows security hole.

~~~
saagarjha
The original title is what the submitter should have used and should not be
the title that the moderators should change it to.

