Tag Info

Hot answers tagged

168

TL;DR The shellshock vulnerability is fully fixed in On the bash-2.05b branch: 2.05b.10 and above (patch 10 included) On the bash-3.0 branch: 3.0.19 and above (patch 19 included) On the bash-3.1 branch: 3.1.20 and above (patch 20 included) On the bash-3.2 branch: 3.2.54 and above (patch 54 included) On the bash-4.0 branch: 4.0.41 and above (patch 41 ...


14

According to the NVD database at NIST (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271), ALL VERSIONS of bash from 1.14.0 onwards are vulnerable. RedHat got wind of the bug on September 14. Patch released by Mr.Ramey (bash maintainer) on Sep-26-2014 fixes the CVE-2014-7169 bug. Apply these and all previous patches to corresponding bash ...


14

For Squeeze use squeeze-lts if possible! (i386 and amd64 only...) append this to your sources.list: deb http://http.debian.net/debian squeeze-lts main contrib non-free deb-src http://http.debian.net/debian squeeze-lts main contrib non-free and then run apt-get update apt-get install -t squeeze-lts --only-upgrade bash Here is more detail on ...


14

The command line arguments of every process in the system is considered "public". Not just the w command, but ps and top and many other commands access that information as a matter of course. Indeed no special privileges are required to get that information. On Linux, you can read the command line of another process, even a process belonging to another user, ...


10

TL;DR (aka executive summary) Yes, you should be worried. Yes, this is severe (giving total strangers potential complete control over your files and resources). You should definitely upgrade your desktop AS WELL AS any servers. ...


9

It is a security risk. That's generally why you can't do it when switching to another context (remote control of a system, changing users, etc). If you have the ability to create any environment variable you want, there are any number of potential ways you can execute arbitrary code. Take $LD_PRELOAD as an example. If you have the ability to set that ...


8

You can use: apt-get install --only-upgrade <package> If is installed, this will upgrade only the specified package.


5

No, it's not safe to pass passwords to programs on the commandline. It's better to use: mohsen@debian:~$ mysql -uuser -p Enter password:


4

As per the official Cygwin Installation Page: Installing and Updating Cygwin for 64-bit versions of Windows Run setup-x86_64.exe any time you want to update or install a Cygwin package for 64-bit windows. The signature for setup-x86_64.exe can be used to verify the validity of this binary using this public key. I had a hunch this bash was ...


4

The security concern is that if a bash is launched with a malicious environment variable set, that bash will execute the code in the variable. For example, lets say you have a web server that calls /bin/foo bar. Lets say this foo application also uses an environment variable called baz, and the value of this variable comes from input provided by the user. ...


4

sudo dpkg -i file.deb will happily execute as root code from the package file.deb. In particular, it'll execute at least the pre- and post-install scripts (which themselves can execute anything, from rm -Rf --no-preserve-root / through custom binary code delivered as part of the package. You should only install packages from trustworthy sources.


3

I'd say it is, when bash is your /bin/sh. It's a not feature of bourne shell, and I'd bet it's not a feature of posix shell either, in fact they might want to expressly forbid it. Bash is really more of korn derivative shell, than a bourne shell, despite its name, and its the only Korn like shell that has the feature, and in my opinion it's kitchensink ...


3

To achive what you want I can propose the following: Create a user for each program. In your example suppose you create a user uxxd (group uxxd). Give it the password you want (form your example 123456) Give the execution rights on this program only to user uxxd: chown uxxd:uxxd xxd chmod 700 xxd For better security you could also remove the login shell ...


2

Debian applied various patches to bash version in wheezy(-security) which also prevents CVE-2014-6277 and CVE-2014-6278 to be exploitable. See https://github.com/hannob/bashcheck/blob/master/README.md how to interpret your result. My output of the (probably updated) bashcheck script on Debian is: Testing /bin/bash ... GNU bash, Version 4.2.37(1)-release ...


2

When you add keys to an authorized_keys file you have several options to restrict what that key can do. In this situation, you can disallow running any commands. Simply prefix it with command="". For example: command="" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDc7nKsHpuC6W/U131p0yDh455sLE9pWmFxdK... When the user wants to connect, they have to pass -N to ...


2

This looks like the version that patched shellshock (Subject to other bug variations / patches.) for cygwin bash: Date: Mon, 29 Sep 2014 15:22:43 -0600 https://cygwin.com/ml/cygwin-announce/2014-09/msg00040.html AKA: 4.1.14-7 " This is a minor rebuild which picks up an upstream patch to fix CVE-2014-7169 and all other ShellShock attacks (4.1.13-6 was ...


2

Ubuntu 12.04 “Precise” and 14.04 “Trusty”, Debian 7 “Wheezy” apt-get update; apt-get install bash Debian 6 “Squeeze” /etc/apt/sources.list.d/squeezelts.list deb http://http.debian.net/debian/ squeeze-lts main contrib non-free deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free /etc/apt/apt.conf.d/50squeezelts ...


2

The command line you are suggesting is secure. All other things being equal, "normal" anonymous pipes (created with the pipe(2) system call or the shell's familiar | syntax) are always going to be more secure than named pipes because there are fewer ways for something else outside the system to get ahold of either one of the ends of the pipe. For normal ...


2

ssh2::exec() returns a stream, which is connected to the stdin, stdout, and stderr of the remote command. So you can do: $command = '/path/to/daemon_adm.py'; $stream = $ssh->exec($command); fwrite($stream, "$text\n"); If you don't want to pass the parameters via stdin, you can use escapeshellarg(): $command = '/path/to/daemon_adm.py ' . ...


2

Complementing the previous answer that correctly states that the installation of packages itself does execute scripts as root during the process, the later execution of the installed software (even by non privileged users) can harm the system and other users files. During the installation process, the scripts (ran as root) can install suid executable files ...


2

It is likely that logrotate has archived the log(s) of interest and opened a new one. If you have older wtmp files, specify one of those, as for example: last -f /var/log/wtmp-20141001


1

To insert a string in a shell snippet and arrange for the shell to interpret the string literally, there are two relatively simple approaches: Surround the string with single quotes, and replace each single quote ' by the 4-character string '\''. Prefix each ASCII punctuation character with \ (you may prefix other characters as well), and replace newlines ...


1

No. The directory that the files are contained within are permissioned so that only the owner of the directory can access them. $ ls -ld ~/.dbus/ drwx------. 3 saml saml 4096 Jan 5 2014 /home/saml/.dbus/ $ ls -ld ~/.dbus/session-bus/ drwx------. 2 saml saml 4096 Jan 18 2014 /home/saml/.dbus/session-bus/ $ ls -ld ...


1

is it possible to port the latest required version of libxml2 to RHEL 4 that way I can use the latest version of ModSecurity? Yes. The ideal way to do this is to install it into /usr/local, presumably building from source. After the build and install, you will need (as root) to run ldconfig to update the linker cache. Libraries in /usr/local/lib ...


1

The version number of a program is not a good indication of the security issues that it has. When a security hole is found, it is standard practice to patch just this hole, and not to upgrade the program to a later version which may turn out to be incompatible in subtle cases. Thus seeing that you have bash 4.1 does not give any information as to whether it ...


1

Block all traffic going out to port 23 of a remote server using your firewall: iptables -A OUTPUT -p tcp --dport 23 -j DROP According to Symantec, the destination is host 72.167.37.182 therefore if you want to be more specific (or need outgoing port 23 to other hosts - hopefully not as it's telnet): iptables -A OUTPUT -p tcp -d 72.167.37.182 --dport 23 ...


1

Save the settings in the user's home directory. Yes, a malware running as the user will be able to delete them. So? A malware that infects the user's account can do whatever your application can do. The only way to hide something from malware is to run with some privilege that the malware doesn't have. This would require the user to give your application ...


1

Unfortunately these are your options: User's home directory /etc Some other designated location on the system There is no magical place you can save your data where it will be impervious to a potential attack. This is why must follow good security practices on the entire machine and make use of a firewall and not install software that hasn't been ...


1

This rundown is the best I've found on the internet about Shell Shock (aka Bash Bug) it explains: The risk centres around the ability to arbitrarily define environment variables within a Bash shell which specify a function definition. The trouble begins when Bash continues to process shell commands after the function definition resulting in what we’d ...


1

The biggest negative is the potential extra load that it may introduce to a server. Now saying that it's typically enabled on CentOS and Fedora, and it's designed to consume as small a footprint as possible so that it can collect these types of detailed audits. So I would fully expect that it won't cause you any issues, assuming the logs are being handled ...



Only top voted, non community-wiki answers of a minimum length are eligible