Hacker News Reader

Comment by vb-8448 | Hacker News Reader

A safer language like RUST won't help you against bad practices and poor QA processes. This is a kind of error that you should catch with automating testing, even before pushing the change to main branch.

View on HN

Not just QA; security assurance, code reviews, static and dynamic testing, threat surface analysis, unit testing, and pentesting either didn’t exist or weren’t sufficiently applied.

I have to imagine that this bug has existed for quite some time and I’d be curious to know what other input validation errors they have, considering the amount of untrusted input they evaluate at ring 0 originating from userland.

Again, there are safe ways of doing this. For example, Wuffs exists: https://github.com/google/wuffs

At the very least, big money security software companies should be parsing untrusted content with some kind of rigorouly safe approach, not just squirting it through a big pile of C/C++.

And don't get me started on the whole concept of undefined behavior in those languages. To quote I. I. Rabi, "Who ordered that?"

>At the very least, big money security software companies should be parsing untrusted content with some kind of rigorouly safe approach

the malformed files were updates from crowdstrike itself. It's not exactly "untrusted content".

It is untrusted data in the sense of files being read from disk that are not part of the signed kernel driver code.

The files in question reside within C:\windows, which requires admin privileges to write to. If untrusted data can end up there, you're already on the other side of the airtight hatchway[1].

[1] https://devblogs.microsoft.com/oldnewthing/20220907-00/?p=10...

Fuzzing...

I'd love to hear from an engineer on the project but unfortunately we're likely not to.

Highly unlikely anyone except governments or top-paying corporations with custom-negotiated T&Cs will see a detailed post-portem, unless someone blows the whistle. Would love to read an AmA.

I agree. My point was that using a language whose compiler will not allow you to build your production binary if you make a certain mistake could have been one extra line of defense and who knows, that might have prevented this problem this one particular time.

But I am in full agreement with you that sloppy programmers cannot truly be helped. They just screw up and move on like nothing happened. Sigh.

You can still do unsafe, and you do need unsafe in some cases.

OK, sure, but don't you think that being a world-wide antivirus vendor should have warranted a better process?

Oh absolutely. This is utterly unacceptable. The ease with which CS pushed willy nilly a bad build to prod in what seems to be a monophasic release is absurd.

Something of this nature would have had our entire team fired. The number of phases and the thoroughness and exhaustiveness of the protocols we have to ensure we don't push bad builds would have most engineers taken aback... but we have to. With great power comes great responsibility.

And human beings can indeed write safe "unsafe" code. But to do so consistently, you have to be very smart, very cautious, and somewhat lucky.

Indeed, ensuring that unsafe is isolated and obeys certain semantics is a superpower that few languages have rust+kani is a good and modern way to achieve this.

Memory-safe lanuages (for goodness' sake, even the crap I write in Python qualifies!) are the very minimum that is needed; not to use them for anything critical is simply crazy. Yes, do all the other things, but at least put out the blazing fire in your basement while you are implementing your fire-safety strategy.

Even with memory-safe languages you can shoot in your foots and on Windows, AFAIK, you need to stick with c/c++ for this kind of low level programming.

BTW, using your metaphor, until 2 days ago they didn't even know that there was a fire in the basement, nor a basement.

How do you write a driver in Python?

Reply on news.ycombinator.com