Live data from Hacker News

Incident Report: CVE-2024-YIKES

nesbitt.io

121–130 of 187 posts

Re: Incident Report: CVE-2024-YIKES

#121
post #58

According to Pangram, this is likely AI generated, surprised that no one has pointed this out

I never used Pangram before today, but since I've seen it mentioned many times on HN and I enjoyed reading the OP, I decided to try it. I am only using the free plan so let me know if I'm missing something. I am assuming the parent was referring to the tool hosted at pangram.com and not some other tool of the same name.

Pangram indeed claims the OP is 76% AI-generated. It has "high confidence" (EDIT: some parts are "medium confidence") that the early portions of the text were created by AI, and "medium confidence" that some of the later potions were written by a human. EDIT: I was especially dismayed to see that the dog might have been an AI creation :(

When I use the "supporting evidence" option, the main piece of evidence Pangram provides is the frequent use of em-dashes. Each timestamp is followed by an em-dash. Personally I think the em-dashes could be a copy-pasted em-dash or inserted by a markdown to HTML converter. nesbitt.io is apparently using Jekyll [0] - any Jekyll users know anything about this??

Pangram's "supporting evidence" feature also considers → and € to be "unusual Unicode".

Personally, to me it looks like the "supporting evidence" feature still needs some work because Pangram's AI detection is probably a lot more sophisticated than a grep for Unicode symbols. In fact the feature even has a notice claiming that "These patterns aren't used to determine our AI score; they help you see why AI text often reads differently."

As for the rest of the OP's content, it would be interesting to compare the Pangram results to a timeline of a real vulnerability. I tried doing so, but exhausted my free "Pangram credits" - apparently the first 1000 words of this article [1] about the log4j vulnerability is considered 100% human.

[0] https://github.com/andrew/nesbitt.io

[1] https://www.csoonline.com/article/571797/the-apache-log4j-vu...

Re: Incident Report: CVE-2024-YIKES

#122

Earlier quoted context omitted.

I couldn't tell at first, tbh. It had this vibe: https://github.com/bitcoin/bips/blob/master/bip-0042.mediawi...

Yeah. Me too. It looked like a spoof when I started reading, but as I went on it didn't seem to be increasing in it's implausibility.

Well, the one I linked to is real. BIP-42 made bitcoin's monetary policy fixed, by fixing a bug in the client which would have resulted in the initial subsidy code being reset every ~250 years or so. It's just the official writeup documenting it that is silly.

Re: Incident Report: CVE-2024-YIKES

#123

Earlier quoted context omitted.

'nmp'

I only noticed at goat farming. But anyway, what would a left-justify package do?

> I only noticed at goat farming

Heh. I didn't even blink at that. I know a couple of open-source folks who actually packed up to buy off-grid farms in Portugal

Re: Incident Report: CVE-2024-YIKES

#126

For anyone confused, this is (very good imo) fiction about supply-chain incidents. It had me very worried during a brief scan that it was real though, which made me read it more attentively :)

Just because it's not important to pay attention to CVEs, why not waste the readers' time by creating "fictional" CVEs without a disclaimer in the first line? Just because it's not already difficult to scrape through the information and noise on this internet... especially if it appears on the front page of hackernews

Re: Incident Report: CVE-2024-YIKES

#127

For anyone confused, this is (very good imo) fiction about supply-chain incidents. It had me very worried during a brief scan that it was real though, which made me read it more attentively :)

"left-justify" absolutely slayed me :)

I should have known when the first package was left-justify, but I read until karen before I realized it must be fiction

Re: Incident Report: CVE-2024-YIKES

#128

For anyone confused, this is (very good imo) fiction about supply-chain incidents. It had me very worried during a brief scan that it was real though, which made me read it more attentively :)

As the victim of the one from last year, it wasn't particularly fun to read.

The implication that I don't know what I'm looking at, or that I don't know what security is (despite having a clean track record for about 15 years now) was a bit aggravating.

In fact, even months later, the lasting effects have been panicking over anything that is remotely suspicious. The most recent example was just a few days ago. Had just gotten on the plane to go on vacation when someone Liked the original "I've been pwned" post on Bluesky. I misread the notification as being a new message to me saying "You've been pwned" and started to panick. I'd have had no way to address it and it would have ruined the small chance per year I get to have a break.

The attack last year wasn't me misunderstanding security. It was the sum of many, many small things (my history with and perception of npm especially w.r.t. their security posture and poor outreach over the years, being stressed out overall, and being in a rush at that particular moment, and a few other personal things) coming together in a perfect storm that resulted in the attack.

Re: Incident Report: CVE-2024-YIKES

#129

It's easy to be cynical because, yes, both the problems and solutions seem dead obvious in hindsight. But for a long time (and maybe even still), a hacker creed was "move fast and break things." It's great that there's so much momentum in fixing the glaring problems with supply chain systems like npm, but I'm concerned that we're entering a new era of security-related problems caused in large part by agentic developm…

We don't need hindsight for the problems of supply chain security to be obvious. Security people were writing and doing talks about this stuff over 10 years ago, just (like most things in security) things start getting addressed once the pressure of incidents gets high enough :)

Re: Incident Report: CVE-2024-YIKES

#130
post #126

For anyone confused, this is (very good imo) fiction about supply-chain incidents. It had me very worried during a brief scan that it was real though, which made me read it more attentively :)

Just because it's not important to pay attention to CVEs, why not waste the readers' time by creating "fictional" CVEs without a disclaimer in the first line? Just because it's not already difficult to scrape through the information and noise on this internet... especially if it appears on the front page of hackernews

Could one mistake this

> Status: Resolved (accidentally)

> Severity: Critical → Catastrophic → Somehow Fine

for a real CVE report?

Post reply on HN