Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
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.
Has anyone heard of any Android mobile devices that use a vulnerable bash?
as expected right. if anything uses the bad bash to do its thing, then it is susceptible to code injection. however, i do not think you can get priv escalation here as bash was called by a specific uid. feel free to correct me if i am wrong.
i dont think Android on mobile devices is an issue......
as expected right. if anything uses the bad bash to do its thing, then it is susceptible to code injection. however, i do not think you can get priv escalation here as bash was called by a specific uid. feel free to correct me if i am wrong.
i dont think Android on mobile devices is an issue......
Isn’t the issue even pointing to to avoid importing shell functions in general if the executed shell runs under a different uid than the one initiating the execution? I mean:
mkdir patched_bash
cd patched_bash
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
tar xaf bash-4.3.tar.gz
cd bash-4.3
for i in {001..026}; do
curl http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i | patch -p0
done
./configure && make
When it's done, you'll have the patched bash executable at patched_bash/bash-4.3/bash
You can then replace /bin/bash with it, or if you like you can keep the old one and symlink this one in it's place:
as root:
Code:
cp -a /bin/bash /bin/bash.old
cp -a patched_bash/bash-4.3/bash /bin/bash.patched
ln -sf /bin/bash.patched /bin/bash
Last edited by suicidaleggroll; 09-26-2014 at 07:28 PM.
I was watching a video where someone was discussing the Shellshock bug and copied the "test" code from an article and then pasted it in the terminal to see the result. In the comments someone made the following statement:
"You shouldn't paste commands directly into the terminal because there's an HTML trick that lets you hide text so as soon as you paste it a malicious command will be executed"
Personally I don't care much for thread titles that only tell half of the story. Of all that's written in that particular thread the most important piece of SELinux-related information is here: https://danwalsh.livejournal.com/71122.html as it clearly explains SELinux still protects against quite a lot compared to machines not running it. That doesn't detract from the fact that no LSM is a catch all, that security (in the sense of hardening, auditing, adjusting) is a continuous process and that this bug again shows Linus's Law has flaws itself.
I was watching a video where someone was discussing the Shellshock bug and copied the "test" code from an article and then pasted it in the terminal to see the result. In the comments someone made the following statement:
"You shouldn't paste commands directly into the terminal because there's an HTML trick that lets you hide text so as soon as you paste it a malicious command will be executed"
Does anyone agree with this?
The essence is nobody (and no information) can (or should) be trusted by default and without proper examination of what such commands do.
You are responsible for what you execute on the systems you're responsible for: you are your own "trigger finger".
What I don't get is why the the bash developers EVER thought it would be a remotely good/safe idea to pull in function declarations from environment variables in the first place.
...
I still don't like the notion of cgi setting http headers as environment variables, and then bash turning environment variables into functions though.
I second this - but I still don't understand why parsing to allow function definitions in env variables is suported at all - it just screams of injection!
The main point is that you may be cutting and pasting text that is not actually visible in the browser. For this reason you should first paste it somewhere safe like a buffer in a text editor to examine it before you run it in your terminal.
Distribution: Debian Testing, Stable, Sid and Manjaro, Mageia 3, LMDE
Posts: 2,628
Rep:
Quote:
Originally Posted by evo2
Hi,
The main point is that you may be cutting and pasting text that is not actually visible in the browser. For this reason you should first paste it somewhere safe like a buffer in a text editor to examine it before you run it in your terminal.
Evo2.
The real question here is; Doesn't every one do it this way?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
