LinuxQuestions.org - [Slackware security] vulnerabilities outstanding 20140101

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - [Slackware security] vulnerabilities outstanding 20140101 (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-security%5D-vulnerabilities-outstanding-20140101-a-4175489800/)

Regarding older versions of Slackware and Bash

@rouvas

http://slackware.osuosl.org/slackwar...source/a/bash/
You can download the Slackbuild from here.

Chet Ramey actually has provided patches for Bash all the way back to version 2.05b.

Update the patches directory in the Slackbuild with the latest patches from here:
http://ftp.gnu.org/gnu/bash/bash-3.1-patches/
http://ftp.gnu.org/gnu/bash/

Build, install ... Done.

Quote:

Note: Those on Bash 4.2 should also re-download the previous patch (bash42-049). It was corrected to apply cleanly.

Huh? The only difference between the old and new patch 049 file is the deletion of a blank line. It applied cleanly before.

Code:

29,34d28

< ***************

< *** 8377,8379 ****

<  }

<  #endif /* HANDLE_MULTIBYTE */

< - 

< --- 8379,8380 ----

Quote:

Originally Posted by MadMaverick9 (Post 5246054)

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.

--mancha

http://www.itnews.com.au/News/396256...effective.aspx

No patches yet? ;)

Something to ponder: http://paste.lisp.org/display/143864

Is this all bash's fault? Or is it the fault of Apache and DHCP allowing bad data being passed on into bash?

The following was copied from http://paste.lisp.org/display/143864, in case it gets deleted:

Quote:

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!

The itnews guy seem to have woke up this morning thinking it's saturday...

50 is up.

bash-4.2.050-x86_64-1_slack14.1.txz

ftp://ftp.slackware.com/pub/slackwar...ches/packages/

From article quoted above:

Quote:

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)?

Quote:

Originally Posted by MadMaverick9 (Post 5246051)

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?

Thanks again,
Rick

@mancha, @MadMaverick9, @Didier Spaier, @moisespedro

thanx all for your swift replies.
I'm waiting for the next maintenance window to apply the said patches.

First known 0day Bash exploit :

http://www.kernelmode.info/forum/vie...&t=3505#p23987

It involves telnet, Busybox and a botnet with a CnC server that changes its IP address every now and then.

There are much more programs prone to exploits that just the CGI modules of Apache.

The dhcpcd server and the botnet described above are more scarier than that, IHMO.

hi, I'm reporting a DoS vulnerability in sysklogd/rsyslog: https://bugzilla.redhat.com/show_bug.cgi?id=1142373
anyone can confirm?

Quote:

Originally Posted by sanjioh (Post 5247153)

hi, I'm reporting a DoS vulnerability in sysklogd/rsyslog: https://bugzilla.redhat.com/show_bug.cgi?id=1142373
anyone can confirm?

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.

--mancha

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.

Even after patching, the old bash binary can still be "ressurrected" from memory
http://stevejenkins.com/blog/2014/09...d-from-memory/