this post was submitted on 22 Jul 2024
808 points (100.0% liked)

196

16359 readers
2246 users here now

Be sure to follow the rule before you head out.

Rule: You must post before you leave.

^other^ ^rules^

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 33 points 2 months ago (1 children)

Considering this is a cybersecurity product that requires installing a kernel mode driver on mission-critical hardware, I guarantee at least a few people would have been interested in looking at the source if they had the opportunity. Or tried to convince their employers purchasing the software to pay for a third-party audit.

The update that broke everything only pushed data, not code. The bug was extant in the software before the update, likely for years. Can I say for sure that a few extra eyes on the code would have found the problem ahead of time? No, of course not. But it couldn't have hurt.

[–] Tar_alcaran 20 points 2 months ago (1 children)

The update that broke everything only pushed data, not code. The bug was extant in the software before the update, likely for years.

A terrifyingly large number of critical issues come to light like this. The code has been broken since the first release, but nobody noticed until a certain edge-case occurs.

[–] [email protected] 15 points 2 months ago

Exactly. Even worse, a bug like this isn't just a crash waiting to happen. It's also a massive security hole.

If an incompetently written file can crash the system, there's a decent chance that a maliciously crafted file could have allowed the complete takeover of it. Memory safety bugs, especially in kernel code, are very serious.

A lack of validation would have been a glaring red flag to any outsider looking at the code, but it's exactly the kind of thing someone who's worked on the software forever could easily overlook. It's so, so easy to lose sight of the forest for the trees.