Down the Rabbit-Hole | Hacker News Reader

Down the Rabbit-Hole

googleprojectzero.blogspot.com

430 pointsjanvdberg84 comments

Open articleView on HN

It looks like it's yet another missed deadline for Microsoft ?

https://bugs.chromium.org/p/project-zero/issues/detail?id=18...

Edit: it's unclear: 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

To be honest, this looks 'broken by design' - it'll probably only get fixed in new versions of windows.

Old versions will get 'fixes' which simply patch the specific flaws found, but there will be always more to find in a complex legacy protocol like this.

> there will be always more to find in a complex legacy protocol like this ..

Wouldn't it be simpler to drop in a CTF replacement unless the ability to read/write to any window, from any other session is generic to Windows.

Wouldn't that completely break all IMEs? I doubt people in Japan, Korea or Taiwan would enjoy not being able to write their language for potentially a very long time.

I can't even imagine how they could fix this, even in a new version of windows. It seems so fundamental that any fix would break backwards compatibility, which is one of their core values.

No, I don't think so.

The protocol in question is entirely internal. They could rip it out and replace it with something totally different, apps shouldn't notice.

The CTF server can also be made to validate its inputs much better, again, no compat impact.

This is another case where Google seems to just take delight in screwing Microsoft and its users here. The 90 day deadline is meant for vendors who don't take security seriously, but Microsoft do. I'm not sure what is gained by releasing this before it's fixed.

> The 90 day deadline is meant for vendors who don't take security seriously, but Microsoft do.

Microsoft dropped the ball for the first 75 days.

> I hope you agree that I adequately communicated this attack to you, it seems like some wires got crossed at Microsoft and it didn't get clearly passed along to the engineering team. We're at day 75 now, I think the solutions I can think of for this attack would require a lot of compat testing with IMEs, so I'm hoping you can expedite this now that we're all on the same page.[1]

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

edit: For clarity, the context of my quote is talking specifically about the session attack, not all issues raised.

Yes, large companies sometimes screw up. The project zero policy on this is wrong and downvotes won't change my mind on that. You know perfectly well that MS will fix it once the right people are in the case, the 90 day "deadline" with working exploit just risks another EternalBlue type situation where the exploit gets used in real attacks and causes real damage, for what?

> You know perfectly well that MS will fix it once the right people are in the case,

No, we don't know that. Companies that were deemed serious have been caught dragging and taking their time with no proof of progress whatsoever (just like in this case?). And think of the message it would send to other (supposedly non-serious) companies: "you've given more time to MS, why not me ? It's only fair".

Just like democracy, the P0 policy is the worst form of disclosure, except for all the others.

Also, please don't conflate this with EternalBlue, there's no remote component here.

> just risks another EternalBlue type situation where the exploit gets used in real attacks and causes real damage, for what?

You mean where the US government decided to not notify Microsoft for 5 years?

Or you mean where Microsoft decided to publicly announce the vulnerability despite not having provided patches for millions of unsupported systems?

These organization the "take security seriously sure make Project Zero look very responsible by comparison.

> for what?

To let people whose security has been compromised for over a decade do what they can to mitigate

They can't do anything to mitigate. What are they meant to do, rewrite parts of Windows by themselves?

The only fixes here come from MS. Until then, the more people that know, the worse it is.

> The protocol in question is entirely internal.

If no third parties have access to it, this sounds promising for a fix. I suspect that third party keyboards and assistive devices probably talk this protocol though...

There's a lot going on here, so there are a lot of potential fixes. The obvious and straightforward ones are the memory safety issues. MS can start fuzzing this software, and fix that stack information leak to better leverage ASLR. This should at least mean that (for one of the described attacks) the attacker needs a new capability (write-what-where or a new infoleak).

I think ForceASLR should improve process randomization across restarts? Not sure. Assuming it does that makes the repeated exploit attempts for one of the attacks harder.

They can start authenticating the API calls to prevent lying about what process/thread you are.

I think these are probably not crazy difficult things for MS to take on. There's a lot more to the attacks here, but seems like those are the places to start. Or just rip this system out and replace it idk.

My expectation is that ripping it out will break a ton of international users language support, handwriting recognition, touch screen keyboards, and voice recognition.

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.

It is very fortunate that it wasn't a zero-day then! I'm not sure if it was a "scramble" since it sounds like from the ticket it was ignored until the deadline got close... although it would be interesting to see the activity on Microsoft's internal bug tracker.

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 - 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?

> "Perhaps that means they're supremely confident they completely understand all facets of the issue and have an airtight solution, and were just flexing by wasting the first 30 days of their embargo."

https://bugs.chromium.org/p/project-zero/issues/detail?id=18...

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.

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.

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.

Perhaps the pressure could have been applied privately. Like researcher gaining access to achieved milestones. As long as Microsoft's progress would have been reasonable, no release.

This issue is very time consuming to fix and very easy to exploit, and it affects a large number of people, directly and indirectly. A full system compromise from unprivileged process or sandbox.

Even if you don't personally use Windows, this might for example be used to compromise your data processed somewhere else.

I completely agree there needs to be very strong pressure on the vendors, and 90 day response is a very effective tool at that. But there should be some kind of alternative way to apply pressure on the vendor in cases that take a long time to fix and cause devastating collateral damage.

Any script kiddie can now start to use this in hours or days.

> Perhaps the pressure could have been applied privately. Like researcher gaining access to achieved milestones. As long as Microsoft's progress would have been reasonable, no release.

Perhaps you should read the thread describing the communication with Microsoft. It sounds to me like the issue was not just the complexity of the bug, but a failure of organization/communication on Microsoft's part.

https://bugs.chromium.org/p/project-zero/issues/detail?id=18...

Yeah, that doesn't look good for Microsoft. I thought they've already learned their lesson, but maybe they need to have a periodic embarrassment for that.

I believe taviso is familiar with Microsoft applying pressure privately.

For example:

https://twitter.com/taviso/status/1160613095523225600?s=19

https://news.ycombinator.com/item?id=20171450

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.

> 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.

> 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.csoonline.com/article/2867534/microsoft-blasts-g...

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

https://googleprojectzero.blogspot.com/p/vulnerability-discl...

https://security.googleblog.com/2010/07/rebooting-responsibl...

https://sites.google.com/site/bughunteruniversity/nonvuln

https://www.google.com/about/appsecurity/reward-program/

https://www.google.com/about/appsecurity/

https://googleprojectzero.blogspot.com/p/vulnerability-discl...

> 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..."

> 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.

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

* 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.

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".

You forgot to include "with pre-built exploit tooling built around what he explicitly said he spent a lot of time on."

Project Zero has done some great things and improved a lot of security, but this feels like a spiteful slap at a competitor. It's not Google is really vulnerable to the same kind of thing, they've long since shown that the security of older versions of their only real public OS is not their concern.

> You forgot to include "with pre-built exploit tooling built around what he explicitly said he spent a lot of time on."

No I didn't; I said everything and I meant everything. If anything, 90 days is overly generous to Google. If they can't get their shit together in three bloody months, fuck them. Of course, this is Google, so fuck them regardless, but this way you have obvious moral high ground.

> Maybe a bit of a dramatization

There's dramatization, and there's outright lying. Nothing will happen to you if you follow your own disclosure policy instead of Google's.

If you also want to participate in the program where you get paid by Google, then sure, you have to play by some of their rules. Similarly, nowhere does Project Zero say they expect to get paid if they don't follow the vendor's rules.

Perhaps there should be more heat on the competition. Microsoft could have found this problem as well, much easier even by reading their own internal documentation. They chose not to care.

> looking at non-competing products with large user bases

Like Linux? McAfee/Kaspersky/Malwarebytes/Symantec? LastPass? LG? Google's own software? Nvidia?

You could require a specific digital signature on your exe to register as a CTF service, and verify the thread IDs when clients connect.

Given the complex nature of the fix, when do you think Microsoft should have started working on it?

This possibility arose 20 years ago according to the article.

To be fair, you should never install a native program that you don't 100% trust. This could presumably be combined with other exploits - a JS vulnerability that gives you control of Chrome, for example - but if you're regularly running untrusted software on Windows (outside of a VM) you probably have bigger problems.

What about the privilege escalation? I can take a lot of care of what I install, but what if some other person use my same computer and is not that careful.

There is no way to securely share a Windows install with untrusted users. Use real VMs.

I wouldn't necessarily dare to install untrusted software on a VM either.

VM escapes are a thing. They have a ton of emulated peripherals, like SATA, ethernet, audio, video/3d, USB HCI, etc. A lot of attack surface. There are still a lot of VM escape bugs to be found.

IMO it's not that clear-cut. A VM is safer than a webpage which is safer than an nacl-plugin, which in turn is safer than an UAP app. But in the end you risk privilege escalation for everything which isn't airgapped.

Right- it's still a big deal, but it isn't a clear and present danger in and of itself for responsible users

What makes you think so? How do you know how many exploits people are sitting on, but not using because they don't have a good sandbox escape exploit?

Well, now they do have an escape. That useless IE/Chrome exploit might be able to suddenly gain SYSTEM privileges.

You can get compromised by such attacks no matter how responsible you are.

I'm sure this isn't a 'forgot to' - rather it is likely a case of a legacy feature / code-base that nobody at Microsoft understood well enough to realize the significance of the vulnerability.

That doesn't excuse it, however given the amount of technical debt I am sure exists in the code base for MS Windows based products... this does not surprise me.

> (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.

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...

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.

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.

> 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.)

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.

> 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.

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.

Yeah, the Linux kernel has no idea what a window is. Someone even made a module adding windows to the kernel to fix that "flaw".

Neither does the Windows kernel.

Sure it does - CreateWindowEx, for example, is a kernel function implemented by win32k.sys. See: https://blogs.msdn.microsoft.com/dsui_team/2012/11/05/troubl...

In the Windows operating system there are multiple components running in kernel-space. One of them is the Kernel.

CreateWindowEx does not run in the Kernel, yet it has parts that run in kernel space.

It's all linked as a single module. Just because they call one subcomponent of that "the kernel", doesn't mean the whole thing isn't the OS kernel, as the general definition means.

Linux also implements most features as separate modules that are linked together, that doesn't mean they aren't all part of the kernel.

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.

https://scorpiosoftware.net/2019/02/17/windows-10-desktops-v...

It depends what level of the OS you’re talking about, but the clean separation is not so clear.

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.

It may be different these days but it used to be the case that all kinds of things would start or require a GUI message loop behind the scenes. Most notoriously, COM STAs did, and all kinds of APIs would enter a COM "apartment" for you as part of their internal operation.

Also just look at the definition of the PEB and TEB. There's plenty of slots for GUI stuff that's just left empty for headless apps, but the space is still allocated. In the end Windows is GUI first with non GUI apps a second class citizen.

https://en.m.wikipedia.org/wiki/Win32_Thread_Information_Blo...

As you can see the primary OS per thread structure has fields like "GDI pen" and "GDI brush". There's no separation of GUI specific stuff from other kinds of apps. Even the EXE file format distinguishes between "an app that will open a window to run in the background" and "a command line app". There's no notion of a program that could be used as both a GUI or a command line app depending on how it's run.

> Most notoriously, COM STAs did, and all kinds of APIs would enter a COM "apartment" for you as part of their internal operation.

You make that sound like that was some kind of accidental leaky abstraction, when in fact it was by design. COM STAs were designed to work with GUI threads, full stop. If you aren't a GUI thread, you shouldn't be initializing yourself with STA COM.

> Also just look at the definition of the PEB and TEB. There's plenty of slots for GUI stuff that's just left empty for headless apps, but the space is still allocated.

I am perfectly fine with that, as it essentially removes thread-local GUI data from the application's TLS namespace. So a few extra pointers exist in the PEB and TEB, big deal.

> In the end Windows is GUI first with non GUI apps a second class citizen.

I don't really see how you can conclude that from STA COM and a couple of TLS slots reserved for the GUI.

> The fundamental IPC primitive is window messages, which is a microkernel-esque very fast inter-thread/process context switch tool.

A fun way to think about Windows, is that it's what Erlang would be if the kernel expected to be able to store GUI state in the process dictionary, such that every actor-process can potentially play a secondary role as a GUI element; and every GUI element is necessarily a first-class actor-process. (These actor-processes being a tree originally rooted in one actor-process holding the kernel state for an OS process—that is, until COM multi-threaded apartments came along and wrecked the abstraction.)

> The fundamental IPC primitive is window messages

That is not remotely true. Windows GUI messages are implemented as part of the win32k.sys device driver via traditional IPC and synchronization mechanisms.

> Other IPC systems you'd expect to be GUI independent like DCOM end up using this under the hood.

That's not entirely accurate either. Yes, DCOM on GUI threads use Windows messaging for IPC for compatibility reasons that go back to OLE on 16-bit Windows.

But the multithreaded apartment (ie, COM for a modern OS) is completely independent from the GUI; it is layered atop Microsoft RPC, which itself uses the NT kernel's ALPC mechanism for IPC.

If you're not creating and working with COM objects on a GUI thread, then you should not be using old-style single-threaded apartment COM. Yes, even if your program is only single threaded, you should still be initializing COM to use the multithreaded apartment.

Yes, I know how COM works. I was a Windows programmer in the past and understand its architecture just fine. You aren't really correct. DCOM doesn't use window messages only on "GUI threads". If you use it in the default way and initialise it as a STA it will create an invisible window for you and even pump the windows message loop for you during an RPC. This will happen even if you didn't create a GUI until that point. The use of window messages is in effect an implementation detail you can't ignore.

Moreover this is the default mode. The CoInitialize API puts you in a STA by default. To get the GUIless MTA you must use the replacement CoInitializeEx API. Obviously COM programmers know this and it's not a big deal, but I don't understand this resistance to accepting that an OS literally called Windows might make windows and window messages an important part of the API.

And I did that window messages run in the kernel, which you accept - even in latest versions the (mandatory) win32k.sys driver implements the message syscalls. I'm not sure how you know what the implementation looks like, but I'm pretty sure it used to be well optimised. It'd be odd if it no longer was.

Now I haven't claimed every IPC primitive in Windows is GUI based, have I? But fundamental features use it, including features like RPC that you wouldn't imagine do so, and that supports my point that it's called Windows for a reason. The GUI aspects historically integrate deeply into everything. As yet one more example, if the dynamic linker encounters a problem during program startup, you get a GUI message box telling you so, even if the program was started from a console.

To understand this, you need to go back to the original release of Windows NT 3.1 in 1993.

Most of the GUI was implemented in user mode. But again, this is 1993, and NT's most popular platform is the x86.

Windows NT 3.5 was code-named "Daytona," and the primary goal of that release was to improve performance.

One way that was achieved was to take the window manager and graphics subsystem, combine them into a device driver (win32k.sys), and run them in kernel mode.

It's not precisely accurate to say that "the kernel" does all of these things, but rather the device driver that contains the window manager performs those operations from within kernel mode.

Over time, Microsoft has been gradually moving some components back into user mode for security and stability reasons, however win32k.sys continues to exist and is frequently the culprit when it comes to Windows security vulnerabilities.

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

"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.

Well, it is his job

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.

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 [...]".

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

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

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

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

In other words, Microsoft literally committed a federal crime (extortion presumably across state lines)? A shame the police did not get involved.

Any response from Microsoft?

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

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

Totally. Un-clickbaity. Title. It’s meaningless. I saw the url and was curious.

Reply on news.ycombinator.com