4 ms·

i like the naivety the page painted C in a bad light because its 50 years old

lolinder 3y ago
> There are other similarities between the two zero-days. They both stem from buffer overflows that allow remote code execution with little or no interaction on the part of an end user other than to visit a malicious webpage. They both affect media libraries that Google published more than a decade ago. And both libraries are written in C, a 50-year-old programming language widely regarded as unsafe because it’s prone to memory-corruption vulnerabilities. Is there something inaccurate or naive in this paragraph?
- simion314 3y ago
  I have no experience with media encoders/decoders but I have a feeling that you have no choice then work with raw bytes and not with high level wrappers because of speed, so I bet you will find similar issues in other languages if anyone wrote such a library in something else then C.
  - sitzkrieg 3y ago
    yea this is where i was gunna go, agreed
    - lolinder 3y ago
      And did you miss all the reasons people gave why that interpretation is itself naive? C's unchecked memory access is the problem, and modern languages have solved it while still allowing writing byte-level code. Claiming that any other language that allows reading and writing raw bytes would have the same issue simply shows you do not understand the problem or the many solutions already available.
      - sitzkrieg 3y ago
        it is also possible to write secure c code, as it is in any other language.
  - lolinder 3y ago
    Working with raw bytes is not the problem, out-of-bounds writes is the problem. A language can allow you to read and write raw bytes while still ensuring (either statically or at runtime) that you aren't able to access memory that isn't yours.
  - btilly 3y ago
    Rust was created for the purpose of having a way to write such code while avoiding this class of issue. And the original use case was specifically to make it easier to make browsers more secure. It's just that there is a lot of legacy code, and the migration to languages like Rust will take a long time.
  - pornel 3y ago
    This vulnerability in libvpx is in boring setup code that runs literally once, and it wouldn't matter if it was 100x slower. Codecs have a lot of "glue" code handling configuration, I/O, and other stuff besides their most performance sensitive bit-pushing loops. But this safe-or-fast dilemma has been mostly solved with Rust (and Wuffs). I am writing codecs in Rust. Rust has many zero-cost abstractions (high level wrappers that get inlined, and compiled for specific types and values you use them with, and it gets optimized as concrete low-level code). This allows writing a lot performance-sensitive code using safe Rust. For example, you don't get redundant bounds checks if you use iterators, and despite being high-level abstraction with chains of iterators and closures, they compile to simple loops, and may even get vectorized (even more so than C, thanks to Rust's stronger no-aliasing and immutability guarantees). When you need something more adventurous, you can dress it in a safe (compiler-verified) higher-level abstraction on top of minimal amount of unsafe code. Even though the underlying unsafe code is as unsafe as C, making a small component out of it helps to review/test/fuzz it in isolation against its interface, rather than test it as part of a complex algorithm.
- thesnide 3y ago
  To be fair, 50 years ago security wasn't as proeminent as today. (Telnet anyone?) Even the way to write C is not the same as 10 years ago. But habits are hard to change. Forcing a change by changing the language is effective. Also, having languages that do more checks is also an option, but has performance impacts. In the end, the weakest link is always the coder. Much more nowadays as they are asked to emit feature faster and faster.
  - pjmlp 3y ago
    Safe system programming was already an issue in the 1960's, ESPOL/NEWP already had unsafe code blocks.

> There are other similarities between the two zero-days. They both stem from buffer overflows that allow remote code execution with little or no interaction on the part of an end user other than to visit a malicious webpage. They both affect media libraries that Google published more than a decade ago. And both libraries are written in C, a 50-year-old programming language widely regarded as unsafe because it’s prone to memory-corruption vulnerabilities. Is there something inaccurate or naive in this paragraph?

simion314 3y ago
I have no experience with media encoders/decoders but I have a feeling that you have no choice then work with raw bytes and not with high level wrappers because of speed, so I bet you will find similar issues in other languages if anyone wrote such a library in something else then C.
- sitzkrieg 3y ago
  yea this is where i was gunna go, agreed
  - lolinder 3y ago
    And did you miss all the reasons people gave why that interpretation is itself naive? C's unchecked memory access is the problem, and modern languages have solved it while still allowing writing byte-level code. Claiming that any other language that allows reading and writing raw bytes would have the same issue simply shows you do not understand the problem or the many solutions already available.
    - sitzkrieg 3y ago
      it is also possible to write secure c code, as it is in any other language.
- lolinder 3y ago
  Working with raw bytes is not the problem, out-of-bounds writes is the problem. A language can allow you to read and write raw bytes while still ensuring (either statically or at runtime) that you aren't able to access memory that isn't yours.
- btilly 3y ago
  Rust was created for the purpose of having a way to write such code while avoiding this class of issue. And the original use case was specifically to make it easier to make browsers more secure. It's just that there is a lot of legacy code, and the migration to languages like Rust will take a long time.
- pornel 3y ago
  This vulnerability in libvpx is in boring setup code that runs literally once, and it wouldn't matter if it was 100x slower. Codecs have a lot of "glue" code handling configuration, I/O, and other stuff besides their most performance sensitive bit-pushing loops. But this safe-or-fast dilemma has been mostly solved with Rust (and Wuffs). I am writing codecs in Rust. Rust has many zero-cost abstractions (high level wrappers that get inlined, and compiled for specific types and values you use them with, and it gets optimized as concrete low-level code). This allows writing a lot performance-sensitive code using safe Rust. For example, you don't get redundant bounds checks if you use iterators, and despite being high-level abstraction with chains of iterators and closures, they compile to simple loops, and may even get vectorized (even more so than C, thanks to Rust's stronger no-aliasing and immutability guarantees). When you need something more adventurous, you can dress it in a safe (compiler-verified) higher-level abstraction on top of minimal amount of unsafe code. Even though the underlying unsafe code is as unsafe as C, making a small component out of it helps to review/test/fuzz it in isolation against its interface, rather than test it as part of a complex algorithm.
thesnide 3y ago
To be fair, 50 years ago security wasn't as proeminent as today. (Telnet anyone?) Even the way to write C is not the same as 10 years ago. But habits are hard to change. Forcing a change by changing the language is effective. Also, having languages that do more checks is also an option, but has performance impacts. In the end, the weakest link is always the coder. Much more nowadays as they are asked to emit feature faster and faster.
- pjmlp 3y ago
  Safe system programming was already an issue in the 1960's, ESPOL/NEWP already had unsafe code blocks.