Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Two points:

- you suggest that software is easy and logical, in that you can triage, locate, and patch the buffer overflow. But in any sufficiently large codebase, there are simply near-unlimited more bugs to find: hence all the memory mitigation’s that have been implemented. So it’s not a robust comparison from the get go.

- there’s constantly increasing research into being able to diagnose & analyze what CNN’s “see”: possibly not to the level and accuracy that you’d expect from lldb, but how long did it take to have really amazing debuggers for binary Applications?



In a normal program, given an exploit, it's easy to understand the idea of attack and specific target of attack. In CNN case, because no one really understands how things work (see https://www.technologyreview.com/s/604087/the-dark-secret-at...), how can they understand why things don't work? The whole contraption is a black box.


What about the latest Intel bug Meltdown? It's not always easy to understand such attacks. Also those involving rare race conditions or things that only worked because a core part of your code depended on undefined behavior can require a major refactoring of your whole code base in order to mitigate.


> The whole contraption is a black box.

That’s not true: there are massive amounts we can glean. Perhaps not as easy as reading the disassembly, but not black box.

That link is far outdated/superseded by modern research:

https://distill.pub/2018/building-blocks/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: