Hacker News Reader

Comment by lopkeny12ko | Hacker News Reader

[flagged]

The thread is still wrong, since it was a OOB memory read, not a missing null pointer check as claimed. 0x9c is likely the value that just happened to be in the OOB read.

Not really, that thread showed only superficial knowledge and analysis, far from hitting the nail on the head, for anyone used to assembly/reverse engineering. Then goes on to make provably wrong assumptions and comments. There is actually a null check (2 even!) just before trying the memory access. The root cause is likely trying to access an address that's coming from some uninitialized or wrongly initialized or non-deterministically initialized array.

What it did well was explaining the basics nicely for a wide audience who knows nothing about a crash dump or invalid memory access, which I guess made the post popular. Good enough for a general public explanation, but doesn't pass the bar for an actual technical one to any useful degree.

I humbly concur with Tavis' take

https://x.com/taviso/status/1814762302337654829

Here are some others for more technically correct details: - https://x.com/patrickwardle/status/1814343502886477857 - https://x.com/tweetingjose/status/1814785062266937588

"Incoming data triggered a out-of-bound memory access bug" is hardly a useful conclusion for a root cause investigation (even if you are of the faith of the single root cause).

No, the Twitter poster is still wrong.

https://threadreaderapp.com/thread/1814376668095754753.html

How can these companies be certified and compliant, etc., and then in practice have horrible SDLC?

What was the impact of diverse teams (offshoring)? Often companies don’t have necessary checks to ensure disparateness of teams does not impact quality. Maybe it was zero or maybe it was more.

Standards generally don't mandate specifics and almost certainly nothing specific to SDLC. At least none I've heard of. Things like FIPS and ISO and SOC2 generally prescribe having a certain process, sometimes they can mandate some specifics (e.g. what ciphers for FIPS). Maybe there should be some release process standards that prescribe how this is done but I'm not aware of any. I think part of the problem is the standard bodies don't really know what to prescribe, this sort of has to come from the community. Maybe not unlike the historical development of other engineering professions. Today being compliant with FIPS doesn't really mean you're secure and being SOC2 compliant doesn't really mean customer data is safe etc. It's more some sort of minimal bar in certain areas of practice and process.

Sadly, I agree with your take. All it is is a minimum bar. Many who don't have the above are even worse --tho not necessarily, but as a rule probably yes.

> How can these companies be certified and compliant, etc., and then in practice have horrible SDLC?

Checklists ?

You're saying there exist a complex software system without a bug despite following best practices to the dot and certified + compliant?

No, but their release process should catch major bugs such as this. After internal QA, you release to small internal dev team, then to select members of other depts willing to dog-food it, then limited external partners then GA? Or something like that so that you have multiple opportunities to catch weird software/hardware interactions before bringing down business critical systems for major and small companies around the planet?

> After internal QA, you release to small internal dev team, then to select members of other depts willing to dog-food it, then limited external partners then GA

What about AV definition update for 0day swimming in the tubes right now?

Sure, those have happened before, but nothing with an impact like last weekend. That's inexcusable. At least definitions can update themselves out of trouble.

What do you refer to "those have happened before"?

Isn't that what happened? Not a software update, not an AV-definition update but more so an AV-definition "data" update. At least that's how I interpret "Rapid Response Content"

It's called Twitter.

No, the name’s been changed.

No it hasn't.

I'm not a fan of Musk or of the-platform-formerly-known-as-Twitter, but I'm not sure how you can insist that the name hasn't been changed.

Reply on news.ycombinator.com