Re:WhatsApp Remote Code Execution in Video Call
by UncleMeat on Tuesday September 27, 2022 @06:58PM
(#33002203)
It is true that memory-safe languages are a massive massive massive boon! I believe that the entire industry needs to be making plans to find a way to shift all applications that operate on untrusted data away from C and C++. But this is completely orthogonal to the purported security benefits of making your source available.
Re:WhatsApp Remote Code Execution in Video Call
by nicoburns on Tuesday September 27, 2022 @07:10PM
(#33002310)
IMO it’s not entirely orthogonal. One of the main benefits (from a security perspective) of open sourcing your app is to allow it to be audited more thoroughly. But even with that kind of auditing it’s hard to make thing secure in non memory safe languages. If you have both, then we might expect open sourcing to more reliably lead to an actually secure app.
Re:WhatsApp Remote Code Execution in Video Call
by UncleMeat on Wednesday September 28, 2022 @08:00AM
(#33006925)
I don't understand. Is the idea that memory errors are too hard to find but that once we've eliminated them at the language level that now auditors can review OSS projects effectively to verify that they are free of vulns? log4j should be a very clear example of how that'll fall over.
Re:WhatsApp Remote Code Execution in Video Call
by pjmlp on Wednesday September 28, 2022 @03:56AM
(#33005341)
C should have been kept as a more type safe than a raw macro assembler.
The problem is that many think they need to write their application using a macro assembler to this day.
Actually, macro assemblers are better than C regarding security, because they don't do optimizations that wipe out code sections.
I suspect once C has been supplanted all the way down the stack it might actually be feasible to eliminate these kind of vulnerabilities entirely for apps where security is of utmost importance.