Paste number 143864: Not a bash bug Pasted by: pjb When: 5 years, 11 months ago Share: Tweet this! | http://paste.lisp.org/+3308 Channel: None Paste contents: Raw Source | XML | Display As text/plain image/svg+xml text/html application/xhtml+xml

I would argue that the bash security concern is not a bug. It is clearly a feature. Admittedly, a misguided and misimplemented feature, but still a feature. The problem is that it was designed 25 years ago. Apache didn't exist yet for five years! Granted, the internet already existed, but it was still a more confidential club. Security in internet software and protocols were often just not considered at all in that time, and definitely not when developping a program such as a shell. So, we're in the context of designing a unix shell, where subprocesses are created and run in a casual and normal manner. When creating a new subprocess, environment variables can be used to pass some data from the parent process to the child process. In the case of bash, it is a feature that has been wanted, to have some functions defined in the parent bash process also be transmitted and defined in the child bash process. Using environment variables to pass the definition of those functions is natural. Where the implementation slightly went beyond the specifications, is that it also executes any command present after the definition of the function passed in an environment variable. Since it's usually the bash program which generates the value of the environment variables used to pass those functions, there's normally no further command. But in the context where bash was designed, if a user added commands to such environment variables, it could be still considered a feature. In any case, the child process is executed on behalf of the user who configured the environment variable, so there's no security consideration to matter. This feature is documented under the -f option of the export built-in command. The implementation detail of using an environment variable whose value starts with "() {" and which may contain further commands after the function definition is not documented, but could still be considered a feature. The problem is that 5 years later, new software was developed (apache, dhcp, etc), that uses bash in child processes, and which still uses environment variables to pass data. Unfortunately, some of that data comes not from the trusted user of the local system, but comes from random users and program on the other side of the internet and of the planet. And in the meantime, the undocumented (and under-published) feature of bash is forgotten. It is an old precept for security on unix systems, that environment variables shall be controlled by the parent processes, and an even older and more general precept that input data shall be validated. Assumedly programs like apache filter out environment variables properly. But unfortunately, in the validation of input data, they fails to validate correctly input data because they don't expect that data starting with "() {" will be interpreted by their bash child processes. If there's a bug, it's not in bash, but in apache and the other internet facing programs that call bash without properly validating and controlling the data they pass to bash. That said, there are some problems with bash, just as with most other software: it is lacking a specifications document, and it has undocumented features. The problem we have is not a bash bug, but is basically similar to the Ariane 5 bug: using a component from an earlier systems out of specifications. The reason why it's used out of specifications in this specific case seems to be that there was no specifications written down, and no documentation of the relevant implementation details. But on the other hand, it is free software and not difficult to check the source to see as the nose in the middle of the face, what is done. When reusing a component with missing specifications and lacking documentation, checking the source of the implementation should be standard procedure, but it has clearly not been done by Apache or DHCP developers. The bug is theirs, just like Ariane 5 bug IS NOT Ariane 4 bug!