4 ms·

Author here. Please post questions, I will try to answer.

koolba 8y ago
No questions but wanted to let you know that’s a fantastic article. I don’t remember when I first read it (too many years back!) but enjoyed it then and enjoyed reading it again.
unilynx 8y ago
You mention some solutions that wouldn't work with SUID programs and that they'd most need the protections.. but is that really a problem? Most of the problems are in the shell expanding command lines before invoking the actual application, so they get protected. Once the application is started, there usually isn't any globbing going on anymore unless those SUID applications invoke shells themselves and pass them user generated data... and then we probably have bigger problems anyway.
- dwheeler 8y ago
  The problems continue. For example, if you are writing a program in Python 3, and directly execute another program with a filename as its first parameter, it is extremely easy to have problems if the file name begins with a dash. Notice this has absolutely nothing to do with shells, you do not need to have a shell at all for this to be a problem. The problem happens in all cases, because the dash is an option indicator in many programs. And that is just one example. As I discussed in the article, even displaying file names can be a big problem because they can include control characters that can control the terminal in which they are being displayed.
  - tedunangst 8y ago
    But the file doesn't need to exist for this problem to occur? All of git, svn, hg have had command injection attacks where a file/repo name became a command option, but none of those cases required that such a file exist.
    - tux1968 8y ago
      This is a really good point that I think pretty much refutes the idea that the fix to this problem is restricting what filenames can be stored in the filesystem. The real issue is enforcing unified and robust command line processing.
      - dwheeler 8y ago
        There is no way to enforce unified command line processing across all possible languages and all possible programs. Even if you did, how would you enforce knowing what a leading dash is? There's no way to tell the difference between a file name and an option, regardless of the programming language used. That also doesn't deal with the problem that you cannot have a list of file names with new lines terminating them, or that merely displaying A filename with control characters can take over a terminal window. In short, even if you could do the impossible, it would not be enough.
        tux1968 8y ago
        All of what you said is true, but that doesn't negate the issue raised in the post to which I responded. Fixing filesystem naming constraints, isn't enough to fix the command line problems you've identified. So if you're going to truly fix command line parsing, you're going to have to do it there. Perhaps offering a library that can eventually be used across the spectrum of utilities and commands.
loeg 8y ago
The article is quite long. Do you have a succinct list of specific recommendations for operating systems? Do you have a succinct list of problems with arbitrary path names for non-shell programs? The two you've mentioned in this thread are (1) passing filenames with leading hyphens as options to other programs via exec(), and (2) printing filenames with terminal control characters.
WhatIsDukkha 8y ago
What's the status of your "Safename" patch? edit- just wanted to say, thanks for picking this fight! It is indeed ridiculous the community hasn't fixed this.
- dwheeler 8y ago
  It is currently in my queue of things that I want to do. However, seriously making a Linux kernel module requires multi hour blocks of time that I have struggled to find. I hope to get back to it.
  - WhatIsDukkha 8y ago
    It seems like this issue would benefit from a github/gitlab page? There are a lot of tracking bugs that would need to be created for fixing userspace by reaching out to other projects, mitigations/workarounds, RFCs for the posix change? etc. It does seem like a big effort but it seems like a worthy fight.
sigil 8y ago
> If you use GNU find and GNU xargs, you can use non-standard extensions to separate filenames with \0 instead. MacOS and the BSDs have had `xargs -0` and `find -print0` for a while now. Time to update that section?

No questions but wanted to let you know that’s a fantastic article. I don’t remember when I first read it (too many years back!) but enjoyed it then and enjoyed reading it again.

unilynx 8y ago

You mention some solutions that wouldn't work with SUID programs and that they'd most need the protections.. but is that really a problem? Most of the problems are in the shell expanding command lines before invoking the actual application, so they get protected. Once the application is started, there usually isn't any globbing going on anymore unless those SUID applications invoke shells themselves and pass them user generated data... and then we probably have bigger problems anyway.

dwheeler 8y ago
The problems continue. For example, if you are writing a program in Python 3, and directly execute another program with a filename as its first parameter, it is extremely easy to have problems if the file name begins with a dash. Notice this has absolutely nothing to do with shells, you do not need to have a shell at all for this to be a problem. The problem happens in all cases, because the dash is an option indicator in many programs. And that is just one example. As I discussed in the article, even displaying file names can be a big problem because they can include control characters that can control the terminal in which they are being displayed.
- tedunangst 8y ago
  But the file doesn't need to exist for this problem to occur? All of git, svn, hg have had command injection attacks where a file/repo name became a command option, but none of those cases required that such a file exist.
  - tux1968 8y ago
    This is a really good point that I think pretty much refutes the idea that the fix to this problem is restricting what filenames can be stored in the filesystem. The real issue is enforcing unified and robust command line processing.
    - dwheeler 8y ago
      There is no way to enforce unified command line processing across all possible languages and all possible programs. Even if you did, how would you enforce knowing what a leading dash is? There's no way to tell the difference between a file name and an option, regardless of the programming language used. That also doesn't deal with the problem that you cannot have a list of file names with new lines terminating them, or that merely displaying A filename with control characters can take over a terminal window. In short, even if you could do the impossible, it would not be enough.
      - tux1968 8y ago
        All of what you said is true, but that doesn't negate the issue raised in the post to which I responded. Fixing filesystem naming constraints, isn't enough to fix the command line problems you've identified. So if you're going to truly fix command line parsing, you're going to have to do it there. Perhaps offering a library that can eventually be used across the spectrum of utilities and commands.

loeg 8y ago

The article is quite long. Do you have a succinct list of specific recommendations for operating systems? Do you have a succinct list of problems with arbitrary path names for non-shell programs? The two you've mentioned in this thread are (1) passing filenames with leading hyphens as options to other programs via exec(), and (2) printing filenames with terminal control characters.

WhatIsDukkha 8y ago

What's the status of your "Safename" patch? edit- just wanted to say, thanks for picking this fight! It is indeed ridiculous the community hasn't fixed this.

dwheeler 8y ago
It is currently in my queue of things that I want to do. However, seriously making a Linux kernel module requires multi hour blocks of time that I have struggled to find. I hope to get back to it.
- WhatIsDukkha 8y ago
  It seems like this issue would benefit from a github/gitlab page? There are a lot of tracking bugs that would need to be created for fixing userspace by reaching out to other projects, mitigations/workarounds, RFCs for the posix change? etc. It does seem like a big effort but it seems like a worthy fight.

sigil 8y ago

> If you use GNU find and GNU xargs, you can use non-standard extensions to separate filenames with \0 instead. MacOS and the BSDs have had `xargs -0` and `find -print0` for a while now. Time to update that section?