We tried many things to get the Wii to connect, without any success. In a last attempt we tried changing the pass phrase to a 64 characters long hexadecimal pass phrase. That did the trick. Both the Wii and both laptops now connect without any problem. So if you are having problems connecting your Wii to the wireless network, try changing the pass phrase to consist of hexadecimal characters (0-9, A-F) only. For WPA/WPA2 it must be exactly 64 characters long.

Back to catching up on LWN issues…

It turned out that the problem was related to the following message that I’ve been seeing in my log:

avc:  denied  { execute_no_trans } for  pid=972 comm="apache2"
name="bash" dev=hda1 ino=26110
scontext=user_u:system_r:httpd_t:s0
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file

The mail() function in PHP (which is what wordpress uses to send the notification mail) is implemented using popen(3). When you call mail(), PHP executes popen(“sendmail …”, “w”). This ends up with a call to “sh -c sendmail …”, which explains the log message.

The solution was allow execute_no_trans for httpd:

allow httpd_t shell_exec_t:file execute_no_trans;

1. Turn on httpd_builtin_scripting and httpd_enable_cgi. Turning on httpd_builtin_scripting gives httpd_t (i.e. apache) permission to read and write files marked httpd_sys_script_rw_t. This is needed for commits to work. Turning on httpd_enable_cgi gives httpd_t permission to execute scripts (marked httpd_sys_script_exec_t), something which is needed for hooks to work.

# setsebool -P httpd_builtin_scripting=1
# setsebool -P httpd_enable_cgi=1

2. Set the proper security context on the files in the repository. Assuming that all repositories are located under /home/svn, the following commands will do the job. Also make sure that the user apache is running as (e.g. www-data) has read access to the repository and write access to the directories dav and db (this is the script I use for that).

# semanage fcontext -a -t httpd_sys_content_t '/home/svn(/.*)?'
# semanage fcontext -a -t httpd_sys_script_rw_t '/home/svn/[^/]+/(dav|db)(/.*)?'
# semanage fcontext -a -t httpd_sys_script_exec_t '/home/svn/[^/]+/hooks(/.*)?'
# restorecon -Rv /home/svn

3. Make sure selinux-policy-refpolicy-dev is installed.

4. Create the directory mysvn. In that directory, create the file mysvn.te with the following contents:

policy_module(mysvn,0.0.1)

require {
        type httpd_t;
        type shell_exec_t;
        type httpd_sys_script_t;
        type var_run_t;
};

# If hooks are shell scripts, apache must be able to run a shell. The
# hooks will run in httpd_sys_script_t.
allow httpd_t shell_exec_t:file rx_file_perms;

# For some reason the scripts searches /var/run
allow httpd_sys_script_t var_run_t:dir search;

5. Then run:

# make -f /usr/share/selinux/refpolicy-targeted/include/Makefile
# semodule -i mysvn.pp

The mysvn policy module is needed because hooks are normally shell scripts. For apache to be able to run them it must be able to run a shell. Once the scripts have started, they run in the httpd_sys_script_t domain.

X.Org

A X.Org security advisory was just announced. There is a bug in X.Org server 6.9/7.0 that allows unprivileged users to execute arbitrary code with root privileges. Apparently the bug was found when examining the results from the analysis that Coverity has been performing on a lot of open source projects (LWN article).

What’s interesting about this bug is that it illustrates how easy it is to make a tiny misstake in C that passes the compiler, doesn’t crash the program at runtime (the code is perfectly legal) but opens up the system for security attacks. They had a tiny typo in the code that checked the effective uid. Instead of checking the return value

if (geteuid() != 0) {...}

they missed the parenthesis which made the expression check if the function’s address was non-zero. Which it always is.

if (geteuid != 0) {...}

Download the patch.

The authors have created two postscript files that, when viewed in a postscript viewer seem to differ, but when passed through a MD5 function produces the same hash. This have the consequent that when a non-suspecting individual electronically signs the “good” document A (by signing the MD5 hash of the document), his signature is also valid for the “evil” document B.

To accomplish this they are using the fact that postscript is really a full blown programming language and that, if MD5(X1) is equal to MD5(X2), then MD5(X1 || X) is equal to MD5(X2 || X). (|| means concatenation.) [1]

This is how they’ve done it…

The first document, document A, looks like this.

%!PS-Adobe-1.0
%%BoundingBox: 0 0 612 792
(S)(S)eq{
[postscript for document A]
}{
[postscript for document B]
}ifelse
showpage

And the second, document B, like this.

%!PS-Adobe-1.0
%%BoundingBox: 0 0 612 792
(T)(S)eq{
[postscript for document A]
}{
[postscript for document B]
}ifelse
showpage

Both S and T are binary blobs of 128 bytes. Expressed in pseudo C, the two documents can be written like this.

if (X == S)
	display(A);
else
	display(B);

X equals S in document A, and T in document B. So each document contains postscript for both documents, and it’s the first 192 bytes that decides which text to show in respective document.

Then, what they have done is finding S and T so that the MD5 hash for

%!PS-Adobe-1.0
%%BoundingBox: 0 0 612 792
(S

equals the MD5 hash for

%!PS-Adobe-1.0
%%BoundingBox: 0 0 612 792
(T

Which apparently took only a couple of hours on a stock PC.

Then they are able to create two, seemingly different documents with the same MD5 hash.

If you’re eager to try this yourself, T and S can be extracted from the order.ps file.

# head --bytes=192 order.ps | tail --bytes=128 > T
# head --bytes=322 order.ps | tail --bytes=128 > S

Hopefully this will make you think twice before signing any postscript document. Or any binary files for that matter. If you follow that advice, the impact of this shouldn’t be that big. But, just too be safe, stop using MD5 as your “hash function of choice”.

[1] – Hash Functions and the Blind Passenger Attack
[2] – Observe that the line endings in the example postscript files are CRLF, not LF.

I can also recommend Cedric Blancher’s recent SecureCon talk (linked from the mail) as it’s fairly interesting. Also linked from the mail is Wifitap which is

a proof of concept for communication over WiFi networks using traffic injection.

You should especially check out the video cracking WEP in 10 easy steps linked to from the Wifitap site. When you’ve done that, reconfigure your access point to use WPA instead. Then read the end of the thread discussing how to crack WPA and return to your AP’s configuration and set a better password.