Guido van Rossum <guido@python.org> writes:

I've tried to look for a way to report OpenBSD bugs, but it appears the only way to report one is by using their sendbug command, which assumes you've got OpenBSD installed. Would someone here be so kind as to report the bug we've found? A pointer to Kurt's last message in this thread should be a good piece of evidence.

I'm not ignoring you, shore.net is delaying inbound messages over 24h and that's slowing me down. The problem is related to the ProPolice "stack smash" protector. It does exactly what I saw: It copies any pointer arguments to an area in the frame below the locally declared buffers. The error appears to be in referencing the original location in the arguments when making the call to load_next(). One of the ProPolice ideas is that a pointer (especially a pointer to a function) can be hacked by a buffer overrun to point to rogue code. www.trl.ibm.com/projects/security/ssp/ The implementation appears to be copying all argument pointers for good measure. I'm looking into this to see if there is a better way to fix the import code. Making a local copy of the pointer fixes the segfault but it's not clear to me yet whether that's a solid fix for all uses of this code in Python. As far as reporting the bug, I can do that once I localize the problem in gcc and see whether it's been fixed. A quick search of the OpenBSD bug database came up dry, but maybe I don't know how to phrase the question yet. -- KBK

Guido van Rossum <guido@python.org> writes:

Double sigh. Strange approach to security.

Their overall approach is outstanding. They understand that the right thing to do is fix insecure code and they audit their base distro extensively. I think they have around a dozen people, including some security professionals, on the audit team. However, it's not possible to audit all the code in the ports, so they have implemented several defensive measures which make it more difficult to mount an attack: 1. ProPolice - anti-stacksmash methods. Sets a canary after the return address, moves local and argument buffers just below that, moves other locals below the buffers, and copies argument pointers into the latter area. If a buffer gets overrun, it nukes the canary. 2. W^X - memory which can be written by an app can't be executed, and vice-versa, assuming MMU support. 3. Non-executable stack @ 3.2 (note that this can cause problems with some functional languages) 4. Greatly reduced use of SUID/GUID binaries. Use of chroot and priviledge separation. It's not surprising there are some residual bugs in the implementation, at least at 3.3. I haven't moved my box to 3.4 yet. -- KBK

Guido van Rossum <guido@python.org> writes:

I've tried to look for a way to report OpenBSD bugs, but it appears the only way to report one is by using their sendbug command, which assumes you've got OpenBSD installed. Would someone here be so kind as to report the bug we've found? A pointer to Kurt's last message in this thread should be a good piece of evidence.

I'm not ignoring you, shore.net is delaying inbound messages over 24h and that's slowing me down. The problem is related to the ProPolice "stack smash" protector. It does exactly what I saw: It copies any pointer arguments to an area in the frame below the locally declared buffers. The error appears to be in referencing the original location in the arguments when making the call to load_next(). One of the ProPolice ideas is that a pointer (especially a pointer to a function) can be hacked by a buffer overrun to point to rogue code. www.trl.ibm.com/projects/security/ssp/ The implementation appears to be copying all argument pointers for good measure. I'm looking into this to see if there is a better way to fix the import code. Making a local copy of the pointer fixes the segfault but it's not clear to me yet whether that's a solid fix for all uses of this code in Python. As far as reporting the bug, I can do that once I localize the problem in gcc and see whether it's been fixed. A quick search of the OpenBSD bug database came up dry, but maybe I don't know how to phrase the question yet. -- KBK

Guido van Rossum <guido@python.org> writes:

Double sigh. Strange approach to security.

Their overall approach is outstanding. They understand that the right thing to do is fix insecure code and they audit their base distro extensively. I think they have around a dozen people, including some security professionals, on the audit team. However, it's not possible to audit all the code in the ports, so they have implemented several defensive measures which make it more difficult to mount an attack: 1. ProPolice - anti-stacksmash methods. Sets a canary after the return address, moves local and argument buffers just below that, moves other locals below the buffers, and copies argument pointers into the latter area. If a buffer gets overrun, it nukes the canary. 2. W^X - memory which can be written by an app can't be executed, and vice-versa, assuming MMU support. 3. Non-executable stack @ 3.2 (note that this can cause problems with some functional languages) 4. Greatly reduced use of SUID/GUID binaries. Use of chroot and priviledge separation. It's not surprising there are some residual bugs in the implementation, at least at 3.3. I haven't moved my box to 3.4 yet. -- KBK