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.
Even after patching, the old bash binary can still be "ressurrected" from memory
But can you add to the environment of a running bash and have it reparse its environment variables?
[sorry, reread the article and saw how it runs from /proc. Can I delete this message?]
Last edited by thirdm; 10-01-2014 at 01:04 PM.
Reason: would like to delete
So, the vulnerabilities Michal Zalewski, of Google, discovered and that I hinted at in post #225 have been made public. Here's a brief
summary for you:
CVE-2014-6277
By traversing a certain code-path, an uninitialized part of memory can end up getting treated as a valid pointer.
The good news is Slackware's Bash uses Bash's malloc version and scrambles memory contents on calls to malloc and free. This
makes things much more difficult to exploit on Slackware because the pointer will always resolve to 0xdfdfdfdf. In other words,
an adversary must find a way to overlap with this particular memory region. On systems where these Bash features are disabled
(and I understand such exist), the pointer can easily be within an attacker's control. Score one for Bob.
CVE-2014-6278
There's a way to trick the Bash parser with what appears to be nested empty command substitutions The reason this tricks the
parser into executing arbitrary code is not clear and seems to only affect versions 4.2 and 4.3 (at least in this form). Pretty much,
the vulnerability allows injection of code through a crafted "functional definition" of an environment variable (much like
CVE-2014-6271 which you can read about in Unshocking the shell).
The good news is the prefix/suffix hardening affords protection against external attackers because untrusted external input should
never be able to set arbitrary environment variables. If they can due to buggy CGI scripts, or otherwise, they could exploit it.
However, if that's true then all bets are off and there's a lot more to worry about than just shellshock and its ugly spawn. Take,
for example, the ability to set SHELLOPTS and LD_PRELOAD to name just a couple.
Stay tuned for upstream patches that fix these two issues (already coming down the pike).
--mancha
Last edited by mancha; 10-01-2014 at 04:44 PM.
Reason: noop
I did use your script (Bash security upgrades for Slackware 12.0, 12.1, and 12.2 [HOWTO]) to update an old server still running Slack 12.1 and that works perfectly. Many thanks for this script.
After the last update (patch level 22), bash on Slack 12.1 now gives this:
Code:
$ env BASH_FUNC_myfunc%%='() { _;}>_[$($())] { echo "evil code here";}' bash -c true
bash: myfunc: line 0: syntax error near unexpected token `{'
bash: myfunc: line 0: `myfunc () { _;}>_[$($())] { echo "evil code here";}'
bash: error importing function definition for `myfunc'
In order to use this same script to update my server with Slack 14.1 I changes it and it seems to work as it does create a new bash-4.2.052-x86_64-1.txz in /tmp. And upgradepkg does work as well.
However, somehow something is going wrong. Bash --version shows that the latest patch is applied but..
Code:
$ bash --version
GNU bash, version 4.2.52(2)-release (x86_64-slackware-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$
$ env BASH_FUNC_myfunc%%='() { _;}>_[$($())] { echo "evil code here";}' bash -c true
evil code here
It still gives 'evil code here'.
Seems I'm doing something wrong, but I have no idea what?
I did use your script (Bash security upgrades for Slackware 12.0, 12.1, and 12.2 [HOWTO]) to update an old server still running Slack 12.1 and that works perfectly. Many thanks for this script.
Hi colweb. Glad the script worked for both your Slackware 12.x and 14.1 systems.
Quote:
Originally Posted by colweb
However, somehow something is going wrong. Bash --version shows that the latest patch is applied but..
Seems I'm doing something wrong, but I have no idea what?
You're doing nothing wrong. The fixes for that issue (CVE-2014-6278) are not yet available. But, as I explain in my report on post #242,
the offending line only works on Bash 4.2 and 4.3 (not 3.1). It is unclear if Bash 3.1 is not vulnerable or simply not vulnerable to that
particular syntax construction.
I saw that post and immediately tried it against the Slackware source, and it seems to patch and build cleanly. Then I realized mancha == mancha. Of course it works!
I expect we'll be seeing a patch from Pat soon?
Last edited by kfritz; 10-03-2014 at 06:21 AM.
Reason: Doh! Can't edit title! It's sysklogd!
the offending line only works on Bash 4.2 and 4.3 (not 3.1). It is unclear if Bash 3.1 is not vulnerable or simply not vulnerable to that
particular syntax construction.
--mancha
To follow up on a report by sanjioh in post #237, there was an issue identified in rsyslog and sysklogd where some invalid priority values
are allowed to propagate through the code. Rainer Gerhards, rsyslog project lead, has prepared two very detailed and well-written advisories
on this: CVE-2014-3634 and CVE-2014-3683.
sysklogd
In the case of sysklogd, this flaw results in out-of-bounds access to an element of the logging daemon's 'filed' structure. So far, my analysis reveals the amount of over/under read is insufficient to go beyond the limits of the structure so a daemon crash doesn't
seem likely. The effect appears limited to improper message handling (or loss) of the message carrying the mal-formed priority value.
However, the rsyslog team has been able to crash rsyslog v3 and its codebase is very similar to sysklogd's. So, I recommend being safe
rather than sorry. (CVE-2014-3634)
Note: This is of more concern for those logging remote messages.
rsyslog
In the case of rsyslog, the impact appears significantly more severe because it's been confirmed the issue can trigger daemon crashes
or possibly code execution. This is complicated by the fact that rsyslog's fix for CVE-2014-3634 was incomplete and introduced the
possibility for large negative out-of-bounds access due to integer overflows. This has since been corrected and assigned CVE-2014-3683.
I don't normally address applications that aren't part of Slackware proper in this thread. But in this particular case, because it was
brought up in sanjioh's original comment, is offered by SBo, shares the root cause with sysklogd, and I'm particularly familiar with the
issue, I'm making an exception. (CVE-2014-3634 and CVE-2014-3683)
Note: This is of more concern for those logging remote messages.
Quote:
Originally Posted by kfritz
http://seclists.org/oss-sec/2014/q4/79
I saw that post and immediately tried it against the Slackware source, and it seems to patch and build cleanly. Then I realized mancha == mancha. Of course it works!
I expect we'll be seeing a patch from Pat soon?
kfritz, we've had a few more back & forths in that thread since my 1st post in case you're interested. Also, yesterday I sent Pat an advance
copy of my patch so there might be an update coming - but I don't know.
--mancha
Last edited by mancha; 10-06-2014 at 03:38 AM.
Reason: Update sysklogd recommendation
Directory traversal attack of CGIHTTPRequestHandler allows running arbitrary executables in the directory under which the server
was started. Fixed in Python 2.7.6. (CVE N/A)
Unbound readline() resulting in denial of service in ftplib and nntplib. Fixed in Python 2.7.6 (CVE-2013-1752)
Unbound readline() resulting in denial of service in imaplib. Fixed in Python 2.7.7 (CVE-2013-1752)
Buffer overflow in the socket.recvfrom_into function in Modules/socketmodule.c allows remote attackers to execute arbitrary code
via a crafted string. Fixed in Python 2.7.7. (CVE-2014-1912) [see also: 20140212 report]
Insufficient bounds checking in the _json module allows an attacker to read arbitrary process memory. Fixed in Python 2.7.8.
(CVE-2014-4616)
The CGIHTTPServer module does not properly handle URL-encoded path separators in URLs. This may enable attackers to disclose
a CGI script's source code or execute arbitrary CGI scripts in the server's document root. Fixed in Python 2.7.8. (CVE-2014-4650)
Integer overflow in bufferobject.c allows context-dependent attackers to obtain sensitive information from process memory via a
large size and offset in a "buffer" function. Fixed in Python 2.7.8 (CVE-2014-7185)
A malicious VNC server could advertise a very large screen size resulting in heap corruption, and possibly remote code execution
on client-side. (CVE-2014-6501)
A malicious VNC server that advertises a large enough screen size could potentially inject code anywhere in client-side process
memory through FramebufferUpdate messages. (CVE-2014-6052)
A malicious client could advertise a very large ClientCutText message size potentially causing a server crash. (CVE-2014-6053)
A malicious client could set the scaling factor to 0, which will result in a server crash. (CVE-2014-6054)
Multiple server-side stack overflows in File Transfer feature. (CVE-2014-6055)
Recommendation: Rebuild LibVNCServer 0.9.9 after applying the following patches:
Exuberant Ctags 5.8, as bundled by Slackware's vim, allows attackers to cause a denial of service (infinite loop and CPU and disk
consumption) via a crafted JavaScript file. (CVE-2014-7204)
Make sure you have a way to kill the process (i.e. other terminal ready to killall -9 ctags) before trying out the PoC because it will
CPU/disk DoS the box. You've been warned, hic sunt dracones:
Back in June, GaZL pointed out the thread was getting difficult to follow. He suggested a state-of-play would help (i.e. summary of which
security issues had been patched and which remained outstanding).
I agree.
So, to mark the 250th post, I bit the bullet and put together the following thread status report (current through 20141014). Mozilla products
are excluded from the list; They usually get Slackware upgrades soon after Mozilla security announcements.
I hope this helps those having trouble sorting all the information out.
hello mancha, and thanks for your amazing work. the recap is wonderful. if I may suggest a further improvement, maybe it would be nice to have it on the first post, to give it more visibility.
what do you think?
I plan to add instructions on disabling SSLv3 to my disabling-SSLv2-on-OpenSSL thread. This might present some compatibility issues but
one would hope POODLE is incentive enough for clients/servers to abandon the 18-year-old protocol.
Meantime, those wanting to disable SSLv3 on Firefox: type about:config in the address bar and change security.tls.version.min from
the default of 0 (SSL 3.0) to 1 (TLS 1.0):
Code:
security.tls.version.min 1
--mancha
Last edited by mancha; 10-15-2014 at 06:32 PM.
Reason: SSL3 is of voting age
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
