Does Haiku have these: https://www.cvedetails.com/vulnerability-list/vendor_id-426/product_id-728/BE-Beos.html? If yes, can they be fixed?
We don’t share a lot of code with BeOS, the exception being the DeskBar and Tracker, and even there we did significant rewrites. So, it is unlikely that we have inherited problems from BeOS. But, our implementation probably has its own bugs and vulnerabilities.
We don’t share a lot of code with BeOS, the exception being the DeskBar and Tracker, and even there we did significant rewrites. So, it is unlikely that we have inherited problems from BeOS. But, our implementation probably has its own bugs and vulnerabilities.
First of all this are all DoS attacks so in case of Haiku OS - a non server target os - it’s not that critical… the only thing which could happen is that your computer / your internet gets slow… one reboot and everything is fine. So at least for desktop os its not such a big problem atm.
Then i would suggest: just test it out… if you are interested in security - you should at least able to perform some of the test (with a friend or a second computer). If there is vulnerability then just open a ticket for this, most of the devs dont read the forum but they will look at the tickets.
CVE-2000-1152 is actually a bunch of otherwise unrelated vulnerabilities in a bunch of BeOS applications, they’re described as denial of service only as a result of laziness of the investigator, it’s pretty obvious that if you scribble ‘AAAAAAA’ into a buffer and get the program to crash at EIP 0x41414141 you’ve got more than denial of service as a possibility.
CVE-2000-0279 would be harder to turn into a remote execution, because there the problem is under-length rather than over-length inputs, so you can’t include a payload easily since there’s no space. It might with further examination be possible to manipulate the target with prior (or even subsequent) packets to get a result other than the denial of service though.
CVE-2000-0276 kinda misses the point, BeOS has no meaningful privilege separation, so if you can run native code then you can crash the OS, finding a novel way to do it hardly matters.
For some of the others you’d need insight into what was actually broken to guess whether it would be further exploitable. For example where BeOS “just hangs” is it in some poorly conceived internal loop because you’ve made a variable wrap, or did it actually run arbitrary code and get stuck that way ? People hungry to score many exploits to make their name don’t care, just label it “DoS” and move on.