7 ms·

CVE-2020-16009 and CVE-2020-15999 are described are "heap corruption". Are those two¹ bugs possible only in memory unsafe programming languages (in other words,

CVE-2020-16009 and CVE-2020-15999 are described are "heap corruption". Are those two¹ bugs possible only in memory unsafe programming languages (in other words, they don't happen with safe programming languages and practices)? ¹=edit: clarified I was referring to the specific bugs

roblabla 6y ago
It's hard to make sweeping claims without knowing what this exact bug looked like (and the associated chromium issue isn't public yet, I believe). Generally speaking, memory-safe programming languages (Java, Safe Rust, Python...) shouldn't have any heap corruption bugs (modulo bugs in their implementation, of course). Memory-safe generally means that memory corruption of all kinds are impossible. But Heap Corruption is a very broad category.
metajack 6y ago
Diane wrote an analysis of how many bugs would have been avoided had the Servo style system been in Gecko all along: https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon... "There’s a significant overlap between memory vulnerabilities and severe security problems. Of the 34 critical/high bugs, 32 were memory-related." Rust doesn't fix everything, and this result won't hold for code that is itself security logic (ie, crypto implementation) as logic errors are also very bad. But fixing memory safety does address almost all the high and critical severity issues. Microsoft published similar research: https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/ https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s... Keep in mind that the Gecko style system has had two decades of work before the Rust code came along, and was written by some excellent programmers. It was extensively fuzzed for years. And still, Rust has enormous potential to solve these security issues. Only time will tell if the next decade with Rust will pan out as the data seem to predict, but I am quite hopeful.
- im3w1l 6y ago
  One question I have, since the JVM, Flash VM, and also Javascript VM seems to have occasional security issues - how confident are we that rustc bugs wont undermine the security of correctly written rust programs?
  - gpm 6y ago
    Confident, not because rustc is written better but because your comment confuses two types of bugs. The bugs you're talking about in JVM, flash, and javascript implementations are bugs that allow malicious code to confuse the language implementation and break out of the programming language defined sandbox. Rust eliminates this class of bugs by not trying to sandbox anything in the first place :P. If you did try and modify rustc to create that type of sandbox, you would fail, rustc is filled with the sort of bugs that allow malicious code to trick the compiler (largely as a result of using llvm as the backend). However the bugs that would undermine the security of correctly written code are a different sort of bug. These are bugs where the compiler takes well defined non-exploitable code and miscompiles it to produce a program that when fed malicious input is exploitable. These bugs are much rarer, because the input to the compiler is not malicious so the compiler is much more likely (almost always) to be on the happy/correct path.
muizelaar 6y ago
CVE-2020-15999 was described as: "A vulnerability exists in the function `Load_SBit_Png`, which processes PNG images embedded into fonts. This function: 1) Obtains the image width and height from the header as 32-bit integers. 2) Truncates the obtained values to 16 bit and stores them in a `TT_SBit_Metrics` structure. 3) Uses the truncated values to calculate the bitmap size. 4) Allocates the backing store of that size. 5) Passes `png_struct` and the backing store to a libpng function. The issue is that libpng uses the original 32-bit values, which are saved in `png_struct`. Therefore, if the original width and/or height are greater than 65535, the allocated buffer won't be able to fit the bitmap." This one could only happen in an memory unsafe programming language. Having bounds checks on the destination buffer would have avoided the problem.
- im3w1l 6y ago
  The issue is in the bindings, which necessarily call libpng in an unsafe way. But if you use known-good bindings it should be prevented. Or if you use a native memory safe library for that matter.
- jeffbee 6y ago
  FreeType is an endless shitshow of security vulnerabilities going back 25 years now. There's really no excuse in 2020 for writing libraries to decode file formats in unsafe languages. Yes, there are performance-sensitive aspects to image decoding, but opening the file and reading two integers is not one of those.
  - projct 6y ago
    I would bet that most libraries chrome uses for file format parsing would not lose any performance at all if rewritten in rust.
    - josefx 6y ago
      You don't even have to drop the remaining zero-days if you apply enough performance hacks using unsafe.
kentonv 6y ago
> Are those two¹ bugs possible only in memory unsafe programming languages CVE-2020-16009 is a bug in V8 (Chrome's implementation of JavaScript). You could write a JavaScript implementation in Rust. However, to achieve acceptable performance, you would almost certainly need to use a lot of "unsafe" code. A performant JavaScript implementation has to be able to generate raw machine code, after all, and then execute it. And the garbage collector probably isn't going to manage memory in a way that the Rust compiler can verify for correctness. So no, "use a memory-safe language" isn't a simple answer to this kind of bug. Using Rust could reduce the attack surface somewhat but certainly would not completely prevent bugs.

roblabla 6y ago

It's hard to make sweeping claims without knowing what this exact bug looked like (and the associated chromium issue isn't public yet, I believe). Generally speaking, memory-safe programming languages (Java, Safe Rust, Python...) shouldn't have any heap corruption bugs (modulo bugs in their implementation, of course). Memory-safe generally means that memory corruption of all kinds are impossible. But Heap Corruption is a very broad category.

metajack 6y ago

Diane wrote an analysis of how many bugs would have been avoided had the Servo style system been in Gecko all along: https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon... "There’s a significant overlap between memory vulnerabilities and severe security problems. Of the 34 critical/high bugs, 32 were memory-related." Rust doesn't fix everything, and this result won't hold for code that is itself security logic (ie, crypto implementation) as logic errors are also very bad. But fixing memory safety does address almost all the high and critical severity issues. Microsoft published similar research: https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/ https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s... Keep in mind that the Gecko style system has had two decades of work before the Rust code came along, and was written by some excellent programmers. It was extensively fuzzed for years. And still, Rust has enormous potential to solve these security issues. Only time will tell if the next decade with Rust will pan out as the data seem to predict, but I am quite hopeful.

im3w1l 6y ago
One question I have, since the JVM, Flash VM, and also Javascript VM seems to have occasional security issues - how confident are we that rustc bugs wont undermine the security of correctly written rust programs?
- gpm 6y ago
  Confident, not because rustc is written better but because your comment confuses two types of bugs. The bugs you're talking about in JVM, flash, and javascript implementations are bugs that allow malicious code to confuse the language implementation and break out of the programming language defined sandbox. Rust eliminates this class of bugs by not trying to sandbox anything in the first place :P. If you did try and modify rustc to create that type of sandbox, you would fail, rustc is filled with the sort of bugs that allow malicious code to trick the compiler (largely as a result of using llvm as the backend). However the bugs that would undermine the security of correctly written code are a different sort of bug. These are bugs where the compiler takes well defined non-exploitable code and miscompiles it to produce a program that when fed malicious input is exploitable. These bugs are much rarer, because the input to the compiler is not malicious so the compiler is much more likely (almost always) to be on the happy/correct path.

muizelaar 6y ago

CVE-2020-15999 was described as: "A vulnerability exists in the function `Load_SBit_Png`, which processes PNG images embedded into fonts. This function: 1) Obtains the image width and height from the header as 32-bit integers. 2) Truncates the obtained values to 16 bit and stores them in a `TT_SBit_Metrics` structure. 3) Uses the truncated values to calculate the bitmap size. 4) Allocates the backing store of that size. 5) Passes `png_struct` and the backing store to a libpng function. The issue is that libpng uses the original 32-bit values, which are saved in `png_struct`. Therefore, if the original width and/or height are greater than 65535, the allocated buffer won't be able to fit the bitmap." This one could only happen in an memory unsafe programming language. Having bounds checks on the destination buffer would have avoided the problem.

im3w1l 6y ago
The issue is in the bindings, which necessarily call libpng in an unsafe way. But if you use known-good bindings it should be prevented. Or if you use a native memory safe library for that matter.
jeffbee 6y ago
FreeType is an endless shitshow of security vulnerabilities going back 25 years now. There's really no excuse in 2020 for writing libraries to decode file formats in unsafe languages. Yes, there are performance-sensitive aspects to image decoding, but opening the file and reading two integers is not one of those.
- projct 6y ago
  I would bet that most libraries chrome uses for file format parsing would not lose any performance at all if rewritten in rust.
  - josefx 6y ago
    You don't even have to drop the remaining zero-days if you apply enough performance hacks using unsafe.

kentonv 6y ago

> Are those two¹ bugs possible only in memory unsafe programming languages CVE-2020-16009 is a bug in V8 (Chrome's implementation of JavaScript). You could write a JavaScript implementation in Rust. However, to achieve acceptable performance, you would almost certainly need to use a lot of "unsafe" code. A performant JavaScript implementation has to be able to generate raw machine code, after all, and then execute it. And the garbage collector probably isn't going to manage memory in a way that the Rust compiler can verify for correctness. So no, "use a memory-safe language" isn't a simple answer to this kind of bug. Using Rust could reduce the attack surface somewhat but certainly would not completely prevent bugs.