5 ms·

Instead of just dogmatically asserting that any C program has security vulnerabilities, and changing C programs is also a security problem, you should look at w

by JdeBP 1y ago

Instead of just dogmatically asserting that any C program has security vulnerabilities, and changing C programs is also a security problem, you should look at what tmux's record actually is. tmux has existed for approaching 18 years, and M. Marriott is still actively improving it as of last week. One can actually look at its record over that time, and, if that record is poor, replace proof by unsupported generalized assertion with proof based upon actual evidence. * https://cvedetails.com/product/20683/Nicholas-Marriott-Tmux.html?vendor_id=11380 https://cvedetails.com/product/20683/Nicholas-Marriott-Tmux....

wat10000 1y ago
That search misses this: https://www.cvedetails.com/cve/CVE-2020-27347/ https://www.cvedetails.com/cve/CVE-2020-27347/ That is still quite a good record, but my statement stands. It is supported by decades of my experience working in C-derived languages. You don't have to accept my experience or believe my statement, of course, it's all the same to me.
- hnlmorg 1y ago
  That's a little like closing the barn door after the horse has already bolted because if you're concerned about security, then running any untrusted software in your terminal multiplexer is already a bad idea, regardless of whether your multiplexer is written in a memory-safe language or not. ...and before someone moans that I'm a C-fanboy, I'm really not. I've been writing software exclusively in memory-safe languages for 10+ years now. But I'm also pragmatic about when arguments about a RiR (rewrite-in-rust) are sensible and when they're not. In tmux's specific case, arguing about security misses the point.
  - wat10000 1y ago
    You never run curl dumping to stdout? You never cat or less a file you downloaded? You never ssh to servers run by other people?
    - hnlmorg 1y ago
      > You never run curl dumping to stdout? Not against untrusted URLs, no. > You never cat or less a file you downloaded? I don’t download untrusted files. > You never ssh to servers run by other people? 100% no. ——- Sounds like what you need more is a VM ;) executing anything untrusted in a secure environment is a dumb move.
    - hnlmorg 1y ago
      Seeming as I'm getting downvoted, let me explain my point better -- and please hear me through because I'm genuinely making some balanced arguments here rather than just viewing things as "black and white": If you care about security enough to be concerned about memory-safety bugs in tmux, then tmux is already a fail, regardless of whether it's written in Rust. I detailed some features in another comment about some of tmux's features that basically make it spyware for untrusted code. And that's got nothing to do with the language it is written in. But assuming you only care about terminal output and trust the software you execute, then you still have a hundred other libraries written in C between and tmux and the internet: openssh, libcurl, openssl, glibc, and so on and so forth. I'd actually welcome seeing many other those rewritten in Rust (or another memory safe language). So rewriting tmux before them is a lot like closing the barn door after the horse has already bolted. Thus if you're genuinely concerned about memory safety security vulnerabilities then the only safe way to work with untrusted output is in a VM. As it happens, this is exactly how highly secure systems operate. Their developers work on VMs which are tightly locked down by the vendor and easy to destroy if they become compromised. Literally the only way to solve the problem you describe is to assume the entire stack is already compromised and thus run it in a sandbox. So does rewriting tmux in Rust improve security? Yes, technically you're right. But it makes almost zero practical benefit compared to everything else. Memory-safety in tmux is not your weak link here. Not even remotely. Disclaimer: I've developed terminal emulators, shells and terminal multiplexers in memory safe languages. My latest project makes heavy use of tmux integrations (again, in a memory safe language) so I'm very familiar with tmux's quirks. I also have a background in DevSecOps. You could almost say this topic is my specialist subject ;) The Rust hype is a generally good thing but misplaced in this very specific discussion.
      - 1y ago

by JdeBP 1y ago

wat10000 1y ago

That search misses this: https://www.cvedetails.com/cve/CVE-2020-27347/ https://www.cvedetails.com/cve/CVE-2020-27347/ That is still quite a good record, but my statement stands. It is supported by decades of my experience working in C-derived languages. You don't have to accept my experience or believe my statement, of course, it's all the same to me.

hnlmorg 1y ago
That's a little like closing the barn door after the horse has already bolted because if you're concerned about security, then running any untrusted software in your terminal multiplexer is already a bad idea, regardless of whether your multiplexer is written in a memory-safe language or not. ...and before someone moans that I'm a C-fanboy, I'm really not. I've been writing software exclusively in memory-safe languages for 10+ years now. But I'm also pragmatic about when arguments about a RiR (rewrite-in-rust) are sensible and when they're not. In tmux's specific case, arguing about security misses the point.
- wat10000 1y ago
  You never run curl dumping to stdout? You never cat or less a file you downloaded? You never ssh to servers run by other people?
  - hnlmorg 1y ago
    > You never run curl dumping to stdout? Not against untrusted URLs, no. > You never cat or less a file you downloaded? I don’t download untrusted files. > You never ssh to servers run by other people? 100% no. ——- Sounds like what you need more is a VM ;) executing anything untrusted in a secure environment is a dumb move.
  - hnlmorg 1y ago
    Seeming as I'm getting downvoted, let me explain my point better -- and please hear me through because I'm genuinely making some balanced arguments here rather than just viewing things as "black and white": If you care about security enough to be concerned about memory-safety bugs in tmux, then tmux is already a fail, regardless of whether it's written in Rust. I detailed some features in another comment about some of tmux's features that basically make it spyware for untrusted code. And that's got nothing to do with the language it is written in. But assuming you only care about terminal output and trust the software you execute, then you still have a hundred other libraries written in C between and tmux and the internet: openssh, libcurl, openssl, glibc, and so on and so forth. I'd actually welcome seeing many other those rewritten in Rust (or another memory safe language). So rewriting tmux before them is a lot like closing the barn door after the horse has already bolted. Thus if you're genuinely concerned about memory safety security vulnerabilities then the only safe way to work with untrusted output is in a VM. As it happens, this is exactly how highly secure systems operate. Their developers work on VMs which are tightly locked down by the vendor and easy to destroy if they become compromised. Literally the only way to solve the problem you describe is to assume the entire stack is already compromised and thus run it in a sandbox. So does rewriting tmux in Rust improve security? Yes, technically you're right. But it makes almost zero practical benefit compared to everything else. Memory-safety in tmux is not your weak link here. Not even remotely. Disclaimer: I've developed terminal emulators, shells and terminal multiplexers in memory safe languages. My latest project makes heavy use of tmux integrations (again, in a memory safe language) so I'm very familiar with tmux's quirks. I also have a background in DevSecOps. You could almost say this topic is my specialist subject ;) The Rust hype is a generally good thing but misplaced in this very specific discussion.
    - 1y ago