SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Huh? The only difference between the old and new patch 049 file is the deletion of a blank line. It applied cleanly before.
If you look closely you'll see:
Code:
patching file parse.y
Using Plan A...
Hunk #1 succeeded at 2851.
Hunk #2 succeeded at 6062 with fuzz 2 (offset -2317 lines).
The patch manpage has an explanation of what "fuzz" means. Chet went through the trouble of fixing it and I personally like clean
patches. I thought others here might also. You are, of course, welcome to disregard my recommendation.
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!
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.
This is rank nonsense.
The grammar production allowed when bash reads in function definitions given in environment variable values should have been {function_body}. Period. Not the full grammar used when you type a command at a prompt or when commands are read from a script.
It is as much a feature to run shell commands while bash reads its environment as it would be a feature for my toilet to give me an impromptu shower each morning.
The point that other programs along the vectors may share blame I'll accept.
One question: do I still need bash-4.2_CVE-2014-7169.diff and bash-4.2_CVE-2014-7186_CVE-2014-7187.diff or are they covered by the official patches (49 and 50)?
Thanks everyone for the great information. I was able to successfully patch my 12.0 server with these files. So, now when I run most of the bug tests I get a negative response, except for CVE 2014-7186/7187. For these I still get a positive response. Has anyone been able to prepare slackware patches for the diff files for these two bugs?
Yes, I can confirm an rsyslog vulnerability with DoS, and potentially RCE, implications. On sysklogd (which Slackware ships by
default) the issue appears limited to mis-addressing (Note: this can only affect you if you enable remote-reception on sysklogd). My
sysklogd fix is ready but I am awaiting a reply from Rainer (my fix also addresses another issue which might affect rsyslog so I have
decided to share with Rainer privately first).
If you do use rsyslog with remote-reception enabled, you should upgrade to the latest versions which address CVE-2014-3634.
thank you mancha. my first concern was about sysklogd, which seems not to be actively maintained upstream, and it's used in slackware as syslogd/klogd.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
