Python is a great programming language, and I use it to write almost all of my tools. But even the best tool cannot protect you from hurting yourself when you don’t know all its edges.
Python has three ways to execute your code for you: You type up a script, and let python run it (python script.py or ./script.py), you start the interactive python console (or use dev-python/ipython which is really neat) or instruct python to run a specific command via an argument (”python -c ‘print 17′”). Now, in the interactive case you often have python files lying around in your current working directory, and want to import them and then test a function. For this reason the current working directory is the first element in the module search path, in Python terms: sys.path[0] = ‘.’. Obviously, this would be a huge mistake when asking Python to run some file; you would not expect virt-manager to load its dependencies from /tmp just because you started it there. The last option, however is the corner case here: The python developers went with the way the interactive shell works, and so this happens:
rbu@peanut /tmp $ echo 'print 1' > re.py
rbu@peanut /tmp $ python -c 'import re'
1
This is not an issue in itself, as it is documented, but it certainly is something you should note when writing scripts that people are supposed to run on multi-user systems. If your shell script in /usr/bin calls “python -c” and people run the script from /tmp, they might end up executing code from Python modules a local attacker had placed there.
And that is how today, we released GLSA 200810-02 for bug 239560, a local root vulnerability “in” Portage. But in the end, it’s not even Portage’s fault. Several ebuilds (among them the ebuild for Portage 2.1 itself) used “python -c” and Portage does not change the working directory when it executes the ebuild’s bash functions. And judging from the ebuild API specification, it does not have to: The ebuilds are the ones that need to make sure Python does not include the current working directory (e.g. export PYTHONPATH). But even those rules are not written in stone, and I hope we bring forward a change of this contract.
So, if you own or distribute any shell scripts that interact with Python, please make sure you keep your Python in its cage. Oh, and check your usage of urllib2.urlopen() while at it.
According to the author the $35 Windows program Folder Lock is “a fast file-security program that can password-protect, lock, hide and encrypt any number of files… Protected files are hidden, undeletable, inaccessible and highly secure”. It even works on “USB Flash Drives, Memory Sticks, CD-RW, floppies and notebooks.”
Now while I still wonder how they protect files from deletion on USB sticks, Charalambous Glafkos found out that the password to encrypt the files is stored in the Windows Registry. For maximum security it is reversed and encrypted with ROT-25.
OpenSSH 5.1 is out, and besides a Security issue that does not affect Linux or the BSDs, it includes a new feature labelled VisualHostKey, aka SSH Fingerprint ASCII Visualisation. Using an idea proposed in the 1999 paper Hash visualization: A new technique to improve real-world security by Perrig and Song, an image with 18×9 resolution is generated from the fingerprint of the SSH server, and is displayed to the client.
Since the feature is experimental, and the algorithm to generate the image should not be considered final yet, display is disabled by default. You can see a test-run in the screen capture, and a (just for fun) list of images of my known hosts. I wonder how long it takes to remember that face… doesn’t it look like bit like Marge Simpson?
Now why all this, you are asking?
It is deemed that images are easier to compare and remember than the usual 32 hex digits, and I believe everyone has to judge by him/herself if that is true. How many of those SSH/OTR/SSL… fingerprint digits do you check*? All of them? Any, at all? Where did you derive your latest Firefox SSL CA certificates from? At a time where I cannot trust my provider to run a secure DNS server, verifying the authenticity of either the other side of communication, or the data in transit is most crucial. Let’s finally get that Tree Signing going!
* If you only check the first 4 digits, and the last 2 — you are riding on a 24 bit fingerprint.
There are only two days left until the LinuxTag in Berlin will start (May 28-31), and Gentoo will be featured with a booth again this year. It’s been some busy weeks for us, and I hope our presentation will turn out to be satisfactory. Even if we do not have the financial backing of other projects.
Speaking of money, if you are still in need of free tickets for all four days, drop me a mail. First come, first served.
If you run any kind of server, especially Debian or Ubuntu, or grant users access to your server, you might want to read the Debian Security Advisory DSA-1571-1 or Ubuntu’s Security Notice USN-612-1 for CVE-2008-0166, and check your encryption keys:
It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch. Furthermore, all DSA keys ever used
on affected Debian systems for signing or authentication purposes should
be considered compromised; the Digital Signature Algorithm relies on a
secret random value used during signature generation.
The first vulnerable version, 0.9.8c-1, was uploaded to the unstable
distribution on 2006-09-17, and has since propagated to the testing and
current stable (etch) distributions. The old stable distribution
(sarge) is not affected.
Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key
material for use in X.509 certificates and session keys used in SSL/TLS
connections. Keys generated with GnuPG or GNUTLS are not affected,
though.
This vulnerability is caused by a patch shipped in Debian, Ubuntu, and other derivatives. Gentoo’s OpenSSL version is not affected, but everyone should check user-provided public keys (such as OpenSSH’s authorized_keys) using the Debian/OpenSSL Weak Key Detector.
Update: Ben Laurie of OpenSSL is making a point that Vendors Are Bad For Security, which I would not follow in that general form. What I have to grant him: Mechanisms of peer review must be employed properly and patches discussed with upstream. If you follow this philosophy, Vendors Are Good For Security.
At Freitagsrunde, we are currently installing an ejabberd Jabber server, and came across the problem of using one SSL certificate for multiple host names. While the old anwer to this problem is using one IP address for each hostname, or wildcard certificates, one of us proposed a solution unknown to the others before: SSL certificates with more than one common name, aka Unified Communications Certificates.
# copy the system's openssl config
$ cp /etc/ssl/openssl.cnf .
# patch
$ cat<<EOF | patch
--- openssl.cnf.orig 2008-04-10 18:01:37.000000000 +0200
+++ openssl.cnf 2008-04-10 18:02:18.000000000 +0200
@@ -141,8 +141,14 @@
organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default =
-commonName = Common Name (eg, YOUR name)
-commonName_max = 64
+0.commonName = Common Name 1
+0.commonName_max = 64
+
+1.commonName = Common Name 2
+1.commonName_max = 64
+
+2.commonName = Common Name 3
+2.commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
EOF
# now create a certificate with this config
$ openssl req -newkey rsa:4096 -nodes -keyout ssl.key -out ssl.pem -config openssl.cnf
...Organizational Unit Name (eg, section) []:
Common Name 1 []:goodpoint.de
Common Name 2 []:*.goodpoint.de
Common Name 3 []:*.*.goodpoint.de
Email Address []:...
And for all remaining sceptics, these certificates will even be signed by CaCert.org:
As our refrigerators and microwaves become part of the internet, their firmware — unexposed before — will be a regular candidate to security research. This CVE was assigned today, discovered by Chris Withers:
CVE-2008-1546:
servlet/MIMEReceiveServlet in the web controller for Mitsubishi Electric GB-50
and GB-50A air-conditioning control systems allows remote attackers to cause
a denial of service (air-conditioning outage) via an XML document containing
a setRequest command.
I’m still hoping for the first GNU/Toaster.
If you are like me and have a lot of good friends that use Debian-based GNU/Linux systems, you were probably envious that their Firefox uses a much nicer icon set, and a different name: Iceweasel. The reason lies within the fact that Debian removes unfree parts (like binary plug-ins) and was therefore forced by Mozilla to use another name and logo, as Firefox’ trademark policy forbids distributing patched versions under that name.
In Gentoo, if you compiled Firefox from source, you could either choose between official branding with the risk of trademark issues if you distribute binary packages, or Firefox’ default theme, “Bon Echo”. Thanks to our Mozilla grandmaster Raúl Porcel (armin76), we now also have the Iceweasel branding available, the USE flag is called “iceweasel”. It does not remove any parts of Firefox except icons and names, that is still your job to do. Thanks, Raúl. I don’t have to envy anymore!
The TU Berlin students of the Freitagsrunde, which I am a part of, organized a series of talks last summer called the Distro Bash. In three sessions Linux and Unix enthusiasts met and discussed merits and flaws of their favorite (or most hated) distribution. Most of the speakers were active users or developers, who studied or worked at the TU Berlin. The talks were rather informal, usually accompanied by live demonstrations. We had about 30 to 40 people attending each session and I learned a lot about how other systems work.
Apparantly, I was not the only to feel this way. Tobias Klauser of the Zürcher Hochschule für angewandte Wissenschaften in Switzerland who heard of (or attended?) our series started an own session of Distro Bashs in the Linux User Group of his university. Too bad I can’t be there, but it’s great to see how our idea travels and evolves. Read more about it in press reports at Pro-Linux and symlink.
Short version: RESTRICT=”mirror” for 24 hours.
Long version:
Fixing some security bugs in teTeX yesterday, I came across a problem that only happens when upstream really messes up: Changing their tarball and leave the same name.
This is disruptive as the user/portage can decide to download either from one of Gentoo’s mirrors or the SRC_URI, but he has one checksum for the file it expects. So we have two options now: Mirror the old file ourselves, changing SRC_URI to mirror://gentoo/ or update the file on our mirrors.
The latter is not a trivial thing to do though: Just changing the checksum and upload the new ebuild could cause serious damage to users. The tarball was 100 MB big and if a user has ten mirrors set up, 1 GB of traffic could be caused before downloading from SRC_URI. Solar came up with a great trick here:
- Change all ebuilds referencing that file to RESTRICT=”mirror“.
- Change the checksum of the distfile.
- Wait a day.
- Remove RESTRICT.
This will probably cause least damage (ok, it’s second to renaming the file). Users with current trees will download the new file from the SRC_URI. If they have the old file still on their disk, portage will download a new one. Users with old trees will find the file on the mirrors until some hours after (2). They have to re-sync or die a very painful traffic-death.
And that’s why you should
- always emerge --sync before updating anything.
- never ever re-release a file with the same name.
