The machines, now inaccessible, are arguably more secure than before.
this post was submitted on 19 Jul 2024
130 points (100.0% liked)
TechTakes
1384 readers
274 users here now
Big brain tech dude got yet another clueless take over at HackerNews etc? Here's the place to vent. Orange site, VC foolishness, all welcome.
This is not debate club. Unless it’s amusing debate.
For actually-good tech, you want our NotAwfulTech community
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Zach Vorhies (who made leaking Google stuff to Project Veritas his entire identity) has the worst possible take: https://twitter.com/Perpetualmaniac/status/1814405221738786984 (lemme gather my thoughts and explain why in the next comment)
Fair warning that I'll be ranty because I hate losers talking about DEI hires.
This is a huge assumption. ~~The last rumor I've read from actual cybersecurity people is that Crowdstrike's update files were corrupt~~ (update: disproven by Crowdstrike's blog post). If this is true it's likely still from programmer error at some level, but maybe not as simple as "whoopsie I forgot an
if (data == nullptr)teehee".He, like the rest of us that don't work at Crowdstrike, has no idea what happened. I have seen computers do the weirdest gosh darn things. I know better than to assume anything at this point. I wouldn't even rule out weird stuff like the data getting corrupted between release qualification and release yet.
This thread is full of these sorts of small technical inaccuracies and oversimplifications so I won't point out all of them, but nothing in the C++ standard requires null pointers to refer to memory address 0x0. Nor does it require that dereferencing a null pointer terminates the program.
Windows died not because C++ asked it nicely to, but because a driver tried to access an address which wasn't paged in.
The funny thing about accessing into non-paged memory in kernel space:
(If this was a simple nullptr dereference on bad input data then perhaps a fuzzer would have helped. Fuzzers are great though I have no idea how hard they are to use with kernel drivers)
Dude would probably call me a "DEI hire"; but I bet I could beat him in a C++ deathmatch so neener neener.
@sailor_sega_saturn And given enough time and enough scale even the most improbably weird things will eventually happen. Update file corrupted by a storage controller that flips a couple of bits at random after every 720 hours of uptime but only if it’s 23.682 seconds after the hour? Weirder shit has happened.
I once helped one of my company's customers troubleshoot an issue that had seen the same ridiculous edge case error happen three times over the course of a few years. At one point the actual sustaining developer we worked with was able to narrow down a specific bit that was getting flipped somehow, and pitched that cosmic radiation was a plausible solution given how rarely this kind of thing impacted other customers.
It was at this point that we remembered that the customer was either a university with a nuclear physics lab or a hospital with a nuclear medicine program (can't remember now, ironically enough) that the server rack lived adjacent to.
some twenty four years ago i managed, amongst others, a company's samba and print server (that was at the time when all the company's servers were beige boxes with less memory and disk than the laptop i'm using to type this – and still they served a few hundred employees).
the machine developed a strange custom of hard-resetting itself, which we initially tracked to specific files being sent for printing; the behaviour was fully reproducible.
as it happened, it was a hardware fault somewhere between the mainboard and the integrated SCSI card; installing a separate SCSI card and reconnecting the disks and backup tape device fixed the problem. (i did not have the budget for a new serwer, no.)
establishing the actual cause took me fucking weeks.