Colin O'Brien

Software Engineer @tines_hq

Previously:
SWE @Datadog
CEO/ Founder of @graplsec
SecEng @Dropbox
SWE @Rapid7

[Colin O'Brien @InsanityBit]

@yarden_shafir @aall86 Also curious bc, afaik, virtually no one uses the various VM/enclaves in Windows.

[Colin O'Brien @InsanityBit]

@Kharosx0 Exploit code is separate from exploitation.

[Colin O'Brien @InsanityBit]

> Microsoft responded in a blog post, saying that releasing exploit code before patches are ready puts users at risk because attackers can immediately use it.

lol no, the users were put at risk by the company producing vulnerable code.

[Pirat_Nation 🔴 @Pirat_Nation]

Microsoft and security researcher Nightmare Eclipse are in a public fight over how security flaws should be handled.

Over recent weeks, Nightmare Eclipse posted working exploit code online for several serious Windows bugs before Microsoft released fixes.
The flaws affect major Windows security features like Microsoft Defender and BitLocker.

The researcher says they first reported the problems privately but claims Microsoft ignored the reports, delayed responses, and shut down their bug reporting account. They then published the details and proof-of-concept code publicly.

On May 27, Microsoft responded in a blog post, saying that releasing exploit code before patches are ready puts users at risk because attackers can immediately use it.

Microsoft also warned it would continue legal action against those enabling cybercrime like Eclipse

Nightmare Eclipse argues they went public because of slow fixes and poor treatment from Microsoft in the past.

[Colin O'Brien @InsanityBit]

@Kharosx0 And the latter is perhaps the case given deep caveats that, to me, make it mostly irrelevant to the discussion.

[Colin O'Brien @InsanityBit]

@Kharosx0 > But how were past our initial point of discussion regarding whether the researcher had 0 responsibility

I don't know that we are. I separated that out as a distinct claim. "0 responsibility" for the vulnerability is totally distinct from "0 responsibility for exploitation".

[Colin O'Brien @InsanityBit]

@Kharosx0 Also you can't assume that public release means that they haven't considered it. Someone can drop a 0 day and 100% genuinely intend for that to be the best way to protect users. And I would suggest that it often is.

[Colin O'Brien @InsanityBit]

@Kharosx0 I think at best you can suggest that intent factors in and that a research does have some sort of ethical obligation to consider consequences. So that's fine, but it doesn't change that the major responsibility is on Microsoft. So is it critical to divvy up a small slot?

[Colin O'Brien @InsanityBit]

@Kharosx0 Sure, we can agree that attackers own a large portion of responsibility when they perform an attack. It just doesn't seem relevant to a discussion that involves a researcher.

[Colin O'Brien @InsanityBit]

@Kharosx0 > I don't think any reasonable person would believe it even possible for software of similar size to contain 0 critical bugs.

I don't think that matters much. (a) Org is responsible whether a problem is tractable or not (b) Far from approaching 0 or even low numbers

[Colin O'Brien @InsanityBit]

@Kharosx0 > I don't think responsibility could be 100% on Microsoft

Then we just fundamentally disagree. The org that ships the vuln is responsible for the vuln existing. There is shared responsibility between the org and the attacker if it is exploited.

[Colin O'Brien @InsanityBit]

@Kharosx0 I don't see any distinction here. Microsoft is responsible for all vulnerabilities in the software that they ship.

[Colin O'Brien @InsanityBit]

"Vuln finders have no responsibility. Dropping 0day is responsible. Responsible companies don't have so many bugs."

This.

Disclosing under a company policy is just one option that you can opt in or out of at your discretion.

[Robert Graham @robertgraham]

We know what probably happened.

From what we see publicly, NightmareEclipse doesn't communicate well, is emotionally immature, and appears to want to extort Microsoft.

Almost certainly, this played a part in the conflict between them and Microsoft -- it's probably as much NightmareEclipse's fault as Microsoft's.

With that said, everything Florian says is correct. It doesn't excuse Microsoft's failures. They are supposed to be the responsible one,

When there is miscommunication or dispute, it's always allowable to drop 0day, regardless whose fault it is. It's Microsoft's job to avoid that, even when they really aren't at fault for the miscommunication.

But Microsoft has convinced themselves of the opposite, that "responsible" disclosure means only the responsibilities of the vuln finder.

Vuln finders have no responsibility. Dropping 0day is responsible. Responsible companies don't have so many bugs.

We let industry subvert the disclosure process. Instead of working to secure their code, vendors have tricked people into believing in the myth of "responsible disclosure", that vendors should be given time to fix and patch their bugs so they are never to blame for the bugs to begin with.

That's why you have customers still buying Fortinet appliances even though their bugs continue to be major sources of customers getting hacked. Customers shrug their shoulders: as long as Fortinet has a vulnerability disclosure program and releases patches, they aren't responsible for when hackers keep breaking into their boxes.

This is garbage. Vendors are still responsible for preventing bugs in the first place, a responsibility that doesn't go away just because they patch.

Regardless of what happened, Microsoft's threats are a gross violation of ethics in the industry.

[Robert Graham @robertgraham]

We know what probably happened.

From what we see publicly, NightmareEclipse doesn't communicate well, is emotionally immature, and appears to want to extort Microsoft.

Almost certainly, this played a part in the conflict between them and Microsoft -- it's probably as much NightmareEclipse's fault as Microsoft's.

With that said, everything Florian says is correct. It doesn't excuse Microsoft's failures. They are supposed to be the responsible one,

When there is miscommunication or dispute, it's always allowable to drop 0day, regardless whose fault it is. It's Microsoft's job to avoid that, even when they really aren't at fault for the miscommunication.

But Microsoft has convinced themselves of the opposite, that "responsible" disclosure means only the responsibilities of the vuln finder.

Vuln finders have no responsibility. Dropping 0day is responsible. Responsible companies don't have so many bugs.

We let industry subvert the disclosure process. Instead of working to secure their code, vendors have tricked people into believing in the myth of "responsible disclosure", that vendors should be given time to fix and patch their bugs so they are never to blame for the bugs to begin with.

That's why you have customers still buying Fortinet appliances even though their bugs continue to be major sources of customers getting hacked. Customers shrug their shoulders: as long as Fortinet has a vulnerability disclosure program and releases patches, they aren't responsible for when hackers keep breaking into their boxes.

This is garbage. Vendors are still responsible for preventing bugs in the first place, a responsibility that doesn't go away just because they patch.

Regardless of what happened, Microsoft's threats are a gross violation of ethics in the industry.

[Jenny Qu @GuanniQu]

found a stack out-of-bounds read in the Linux kernel's nftables pipapo set backend (CVE-2026-43453, CVSS 7.1). I found it by looking for a specific pattern that I think is underhunted, so I want to talk about the methodology as much as the bug.
the pattern: function calls where one argument is a boundary-dependent expression and another argument is a flag that makes the callee skip using it. in C, this is a trap. the callee's early return makes every reviewer think the dangerous argument is inert. it is not. C evaluates all arguments at the call site before the function is invoked. the callee's control flow has no jurisdiction over argument evaluation. so you get these call sites that look safe, that have been reviewed and re-reviewed and look safe every time, because the question everyone asks is "is this value used?" and the answer is no. the question that matters is "is this value evaluated?" and nobody asks it because in most languages it's the same question.
so I started grepping function calls where an argument indexes an array, and a separate argument is a boolean that triggers an early return in the callee. the kind of code where someone wrote a guard clause and everyone downstream trusted it to cover the arguments too. it doesn't. it can't. the arguments are already computed.
pipapo_drop() in nft_set_pipapo.c:
pipapo_unmap(f->mt, f->rules, rulemap[i].to, rulemap[i].n, rulemap[i + 1].n, i == m->field_count - 1)
on the last iteration, i == field_count - 1. rulemap[i + 1].n reads past the end of a stack-allocated array of 16 entries. pipapo_unmap() checks is_last, returns immediately, never touches the value. the value is already read. the OOB is in the caller's scope. five years of this code in production and every review pass concluded "the function doesn't use it" which is true and also completely beside the point.
the reason I think this pattern is underhunted: static analyzers flag unused variables and unchecked return values but I haven't seen one that asks "is this argument expression legal in the caller's scope given that the callee might not use it?" the safety of the expression depends on the callee's behavior, but the evaluation of the expression doesn't. that gap is where bugs live for years. maybe decades. the callee being careful is what makes the bug invisible. the better the function handles its arguments, the longer the OOB at the call site survives review. that's perverse. the code's own correctness is camouflaging the bug.
when field_count is 16 (NFT_PIPAPO_MAX_FIELDS, the max), rulemap[16].n is real stack OOB. you're reading whatever the kernel left on the stack before your frame. smaller field counts get you uninitialized entries in your own array instead, which is a different flavor of wrong but still wrong. and this isn't some exotic race you trigger with three threads and a prayer. it's the normal path. every element expiration, every deletion. the kernel's own GC walks into it on a timer.
KASAN on 7.0.0-rc2 aarch64 confirmed it: Read of size 4 at addr ffff8000810e71a4. one stack object, [32, 160) 'rulemap', buggy address at offset 164. array is 128 bytes. read is 4 bytes past the end. rulemap[16].n. worked the offset math on paper beforehand.
PoC: pipapo set with NFT_SET_INTERVAL | NFT_SET_CONCAT | NFT_SET_TIMEOUT, 16 concatenated 4-byte fields. insert element, 1-second timeout. wait. insert another to trigger nft_pipapo_commit() → pipapo_gc() → pipapo_drop() → OOB. no heap shaping. no race. the kernel GC walks into it on a schedule.
reported to [email protected]. Willy Tarreau forwarded to netfilter maintainers. Florian Westphal reviewed, confirmed, asked for a readability tweak. the fix:
last ? 0 : rulemap[i + 1].n, last
I think there are more of these in the kernel. any function that takes a flag argument and an expression argument where the flag makes the expression unnecessary. every one of those call sites is a candidate for an OOB or an uninitialized read that no reviewer will catch because the callee's guard clause is too convincing. the code review feedback loop is broken for this pattern. the only reliable way to find them is to stop reading the callee entirely and ask whether every argument is legal to evaluate in the caller's scope, regardless of what the function plans to do with it.
patched in stable 5.10–6.19.

[Colin O'Brien @InsanityBit]

@Thunder_Chicken Sure. Regulate engineering if you'd like, I'll support it.

[Colin O'Brien @InsanityBit]

TBH I unironically think that this is the case and it's why I don't care if people just drop 0days on twitter. Don't want 0days dropped? Stop writing shit software.

[thaddeus e. grugq @thegrugq]

Microsoft could stop researchers bothering them with security bug reports by simply not writing security bugs into their software.

[Colin O'Brien @InsanityBit]

@Thunder_Chicken I guess my point is that I'm good with whatever. It's up to companies not to have vulns.