5 ms·

Image libraries are exactly where we need rust-style safe code.

by ape4 10y ago

zzzcpan 10y ago
No, image libraries is exactly where performance always beats safety and where other approaches to secure them actually work, like sandboxes and containers, and kind of have to be used anyway, since memory safety doesn't guarantee that unpacking an image won't DoS the system.
- steveklabnik 10y ago
  "Performance beats safety" is a dichotomy that Rust is attempting to fundamentally reject. Safety often means you can go faster, not slower, but it depends on context, of course.
  - btrask 10y ago
    Rust tightly couples performance and safety. Sandboxing separates out performance and safety, so you can take your pick of languages for performance, and your pick of sandboxes for safety, without conflict.
- Tobu 10y ago
  Containers provide resource limits but not necessarily safety. The ABI surface is too large. You kind of need the code inside them to be secure.
  - zzzcpan 10y ago
    Hmm, what large surface? You only need like a couple of syscalls for an image decoder, it doesn't need anything else from the OS and is supposed to be short-lived.
    - pcwalton 10y ago
      > You only need like a couple of syscalls for an image decoder, it doesn't need anything else from the OS and is supposed to be short-lived. Not if you're going to take advantage of hardware acceleration.
- stymaar 10y ago
  Sandboxes and, to a certain extend, containers, are mitigation techniques ! Since you cannot trust the program you run on the server, you add an additional layer to reduce the risk that an attacker does harm before the vulnerabilities are found and patched. I know nobody who doesn't apply security patches for his software because he uses containers … If you can get rid of half of the security risks by using software that are free for memory-born vulnerabilities, that's a win. That's what Rust is about.
  - zzzcpan 10y ago
    Bounds checking and panicing are similar mitigation techniques and not an actual freedom from memory-born vulnerabilities, just take place directly in the code, not on the OS level. Things are a bit more complicated with image libraries though, because a) performance is usually critical and b) even if you have that casual use case and it's not yet critical, memory safety is still not going to make it free from vulnerabilities to accidental DoS attacks (not even talking about malicious users here!), unless you apply those mitigation techniques and deploy supporting infrastructure to prevent process from using all memory and all CPU and take too long, etc.
    - stymaar 10y ago
      > Bounds checking and panicing are similar mitigation techniques and not an actual freedom from memory-born vulnerabilities Absolutely. Bounds checking is a mitigation technique to avoid potential footgun when you want/have to use manual array indexing. In most situations in Rust, you use iterators instead of array indexing. Those are the «actual freedom from memory-born vulnerabilities» and have no associated overhead. Since it is known at compile time that you are not going to access invalid memory, there is no need for bounds checking in this scenario. Most of rust safety comes from clever compile time checks with no additional cost at runtime. The two main counter-examples I can think of are : - bounds checking on manual array indexing - usage of a secure hash function by default in HashMaps The whole story about safe multi-threading and dangling pointers prevention is totally free performance-wise: everything is checked at compile time by the borrow checker. > memory safety is still not going to make it free from vulnerabilities to accidental DoS attacks (not even talking about malicious users here!) You're right, Rust doesn't solve all the problems at once. Is it a good reason to get rid of the benefits of solving the worst 50% of problems ?
- valarauca1 10y ago
  here other approaches to secure them actually work, like sandboxes and containers, "It is a fallacy to think that for 30+ years people haven't been able to write a secure OS. But virtualization, and containers are" - Theo de Raant
  - nickpsecurity 10y ago
    GEMSOS, KeyKOS, ASOS, LOCK, VAX VMM, INTEGRITY-178B, seL4, NOVA... all in the 4Kloc-50+Kloc range for a reason. All simpler, smaller, and easier to model than a full OS. Two survived pentesting by NSA with others during validation way better in defect rate or correctness case than most OS's. Theo's quote is BS by the numbers and pentest results. Sandboxing done right is way more secure.
    - lobster_johnson 10y ago
      While true, in practical terms, those OSes are not what people have lying around to do their image processing. I'd love a secure, formally verified, capabilities-based microkernel OS as much as next person, but all I have is Linux and various BSDs. It's a bit academic at this point.
      - nickpsecurity 10y ago
        The commenter countered that sandboxing was worthwhile by citing a claim by Theo de Raadt that getting those (i.e. VM's) right was about as hard as getting whole OS's of code right. That one proved futile meant the other would. I countered that citation with numerous examples that disprove his point. Then, by implication, sandboxing might be effective if it's done like in my examples. And there are CompSci designs doing stuff like that. Whether you want to do image processing on a Linux, BSD, or one of my kernels is a separate topic. However, it's worth noting that even stuff like I cited could be useful for that where it stashes the image processor into its own protection domain with read access to memory containing input and write access to memory that will have the output. The code itself isn't allowed to do or touch anything else. At this point, exploits must be chained in clever ways. Modifying this to preserve pointer integrity, lowest overhead range being around 1-10%, would choke those kind of attackers further. Using Rust is yet another tactic that can work well with or in lieu of a sandbox. Ideally with for issues the language itself can't cover. Three precedents for that are right on my list: GEMSOS's safety was improved using a Pascal subset with call-by-value semantics; ASOS was a combo of security kernel and Ada runtime to host embedded, Ada applications (lang-safety + sandbox); separation kernels like INTEGRITY-178B usually support runtimes for Ada and Java subset to get safety within components. Now, there's some OS's like Tock and Redox plus low-level libraries written in a new, safety-enhancing language. Such designs can benefit from the old strategies which we see a few in Redox. On other end, Genode uses many old and recent tricks in architecture but not safe language. It can also run a Linux desktop with your image processing code. ;) Note: A bit academic is also misleading. Several, separation kernels are deployed commercially for things like secure, web browsing. INTEGRITY and LynxSecure are among oldest. The Nizza and Perseus architectures got turned into Sirrix's Turaya Desktop. These things aren't just academic.
- pcwalton 10y ago
  > No, image libraries is exactly where performance always beats safety and where other approaches to secure them actually work, like sandboxes and containers, and kind of have to be used anyway, since memory safety doesn't guarantee that unpacking an image won't DoS the system. Sandboxes have significant performance costs of their own: the cost of spawning and communicating with a separate process, in addition to the extra memory use of a multiprocess architecture. They also come with high engineering overhead: creating a Chromium-like sandbox is a lot of work (which is why so few apps go to the trouble), and it's easy to mess up and accidentally introduce sandbox escapes. There is the attack surface of the kernel and IPC layer. Finally, what seems at first to be a simple IPC interface between the image decoder and the host application becomes a lot more complex when hardware acceleration (GPU or otherwise) becomes involved. Securely providing a decoder access to hardware (say, to perform iDCT or colorspace conversion) is a nontrivial task. This comment didn't deserve to be downvoted, as it's a legitimate argument. But when you add up all of these costs compared to just having a system that prevents memory safety issues in the first place, the Rust approach is rather appealing. (Oh, by the way: Preventing image DoS isn't as hard as it sounds. Refusing to decode images larger in area than some limit gets you most of the way there.)

Image libraries are exactly where we need rust-style safe code.

by ape4 10y ago

Image libraries are exactly where we need rust-style safe code.

No, image libraries is exactly where performance always beats safety and where other approaches to secure them actually work, like sandboxes and containers, and kind of have to be used anyway, since memory safety doesn't guarantee that unpacking an image won't DoS the system.

steveklabnik 10y ago
"Performance beats safety" is a dichotomy that Rust is attempting to fundamentally reject. Safety often means you can go faster, not slower, but it depends on context, of course.
- btrask 10y ago
  Rust tightly couples performance and safety. Sandboxing separates out performance and safety, so you can take your pick of languages for performance, and your pick of sandboxes for safety, without conflict.
Tobu 10y ago
Containers provide resource limits but not necessarily safety. The ABI surface is too large. You kind of need the code inside them to be secure.
- zzzcpan 10y ago
  Hmm, what large surface? You only need like a couple of syscalls for an image decoder, it doesn't need anything else from the OS and is supposed to be short-lived.
  - pcwalton 10y ago
    > You only need like a couple of syscalls for an image decoder, it doesn't need anything else from the OS and is supposed to be short-lived. Not if you're going to take advantage of hardware acceleration.
stymaar 10y ago
Sandboxes and, to a certain extend, containers, are mitigation techniques ! Since you cannot trust the program you run on the server, you add an additional layer to reduce the risk that an attacker does harm before the vulnerabilities are found and patched. I know nobody who doesn't apply security patches for his software because he uses containers … If you can get rid of half of the security risks by using software that are free for memory-born vulnerabilities, that's a win. That's what Rust is about.
- zzzcpan 10y ago
  Bounds checking and panicing are similar mitigation techniques and not an actual freedom from memory-born vulnerabilities, just take place directly in the code, not on the OS level. Things are a bit more complicated with image libraries though, because a) performance is usually critical and b) even if you have that casual use case and it's not yet critical, memory safety is still not going to make it free from vulnerabilities to accidental DoS attacks (not even talking about malicious users here!), unless you apply those mitigation techniques and deploy supporting infrastructure to prevent process from using all memory and all CPU and take too long, etc.
  - stymaar 10y ago
    > Bounds checking and panicing are similar mitigation techniques and not an actual freedom from memory-born vulnerabilities Absolutely. Bounds checking is a mitigation technique to avoid potential footgun when you want/have to use manual array indexing. In most situations in Rust, you use iterators instead of array indexing. Those are the «actual freedom from memory-born vulnerabilities» and have no associated overhead. Since it is known at compile time that you are not going to access invalid memory, there is no need for bounds checking in this scenario. Most of rust safety comes from clever compile time checks with no additional cost at runtime. The two main counter-examples I can think of are : - bounds checking on manual array indexing - usage of a secure hash function by default in HashMaps The whole story about safe multi-threading and dangling pointers prevention is totally free performance-wise: everything is checked at compile time by the borrow checker. > memory safety is still not going to make it free from vulnerabilities to accidental DoS attacks (not even talking about malicious users here!) You're right, Rust doesn't solve all the problems at once. Is it a good reason to get rid of the benefits of solving the worst 50% of problems ?
valarauca1 10y ago
here other approaches to secure them actually work, like sandboxes and containers, "It is a fallacy to think that for 30+ years people haven't been able to write a secure OS. But virtualization, and containers are" - Theo de Raant
- nickpsecurity 10y ago
  GEMSOS, KeyKOS, ASOS, LOCK, VAX VMM, INTEGRITY-178B, seL4, NOVA... all in the 4Kloc-50+Kloc range for a reason. All simpler, smaller, and easier to model than a full OS. Two survived pentesting by NSA with others during validation way better in defect rate or correctness case than most OS's. Theo's quote is BS by the numbers and pentest results. Sandboxing done right is way more secure.
  - lobster_johnson 10y ago
    While true, in practical terms, those OSes are not what people have lying around to do their image processing. I'd love a secure, formally verified, capabilities-based microkernel OS as much as next person, but all I have is Linux and various BSDs. It's a bit academic at this point.
    - nickpsecurity 10y ago
      The commenter countered that sandboxing was worthwhile by citing a claim by Theo de Raadt that getting those (i.e. VM's) right was about as hard as getting whole OS's of code right. That one proved futile meant the other would. I countered that citation with numerous examples that disprove his point. Then, by implication, sandboxing might be effective if it's done like in my examples. And there are CompSci designs doing stuff like that. Whether you want to do image processing on a Linux, BSD, or one of my kernels is a separate topic. However, it's worth noting that even stuff like I cited could be useful for that where it stashes the image processor into its own protection domain with read access to memory containing input and write access to memory that will have the output. The code itself isn't allowed to do or touch anything else. At this point, exploits must be chained in clever ways. Modifying this to preserve pointer integrity, lowest overhead range being around 1-10%, would choke those kind of attackers further. Using Rust is yet another tactic that can work well with or in lieu of a sandbox. Ideally with for issues the language itself can't cover. Three precedents for that are right on my list: GEMSOS's safety was improved using a Pascal subset with call-by-value semantics; ASOS was a combo of security kernel and Ada runtime to host embedded, Ada applications (lang-safety + sandbox); separation kernels like INTEGRITY-178B usually support runtimes for Ada and Java subset to get safety within components. Now, there's some OS's like Tock and Redox plus low-level libraries written in a new, safety-enhancing language. Such designs can benefit from the old strategies which we see a few in Redox. On other end, Genode uses many old and recent tricks in architecture but not safe language. It can also run a Linux desktop with your image processing code. ;) Note: A bit academic is also misleading. Several, separation kernels are deployed commercially for things like secure, web browsing. INTEGRITY and LynxSecure are among oldest. The Nizza and Perseus architectures got turned into Sirrix's Turaya Desktop. These things aren't just academic.
pcwalton 10y ago
> No, image libraries is exactly where performance always beats safety and where other approaches to secure them actually work, like sandboxes and containers, and kind of have to be used anyway, since memory safety doesn't guarantee that unpacking an image won't DoS the system. Sandboxes have significant performance costs of their own: the cost of spawning and communicating with a separate process, in addition to the extra memory use of a multiprocess architecture. They also come with high engineering overhead: creating a Chromium-like sandbox is a lot of work (which is why so few apps go to the trouble), and it's easy to mess up and accidentally introduce sandbox escapes. There is the attack surface of the kernel and IPC layer. Finally, what seems at first to be a simple IPC interface between the image decoder and the host application becomes a lot more complex when hardware acceleration (GPU or otherwise) becomes involved. Securely providing a decoder access to hardware (say, to perform iDCT or colorspace conversion) is a nontrivial task. This comment didn't deserve to be downvoted, as it's a legitimate argument. But when you add up all of these costs compared to just having a system that prevents memory safety issues in the first place, the Rust approach is rather appealing. (Oh, by the way: Preventing image DoS isn't as hard as it sounds. Refusing to decode images larger in area than some limit gets you most of the way there.)