> The bug against libgcrypt11 is the same as that against libssl0.9.7 -- the > library has explicitly requested an executable stack. I don't think this is > a coincidence:
Indeed, this is not coincidence. Both libraries have optimized versions of some function implemented in assembly. But .note.GNU-stack,"",@progbits is missing in the assembly sources. Missing markers means executable stack, so the entire library gets marked as PT_GNU_STACK RWE. See also https://www.redhat.com/archives/fedora-devel-list/2005-March/msg00460.html > it's pretty likely that both of these libraries *use* the executable stack, No, these libraries _do not_ need an executable stack (e.g., why calculation of MD5 hash could ever need it?). As a matter of fact, marking stack as non-executable sudo execstack -c /usr/lib/i686/cmov/libssl.so.0.9.7 did not break anything. > The last bug, I'm leaving assigned to glibc, since that is the package > whose behavior change triggered these reports. AFAIK, the only glibc change that made these bugs explicit is hwcap support. Here is short demonstration: (downgrade to glibc-2.3.2.ds1-22) $ ldd /usr/bin/ssh libresolv.so.2 => /lib/libresolv.so.2 (0x27486000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x27498000) libutil.so.1 => /lib/libutil.so.1 (0x275a0000) libz.so.1 => /usr/lib/libz.so.1 (0x275a3000) libnsl.so.1 => /lib/libnsl.so.1 (0x275b8000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x275cd000) libselinux.so.1 => /lib/libselinux.so.1 (0x275fa000) libc.so.6 => /lib/libc.so.6 (0x2760c000) libdl.so.2 => /lib/libdl.so.2 (0x2773f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x27465000) execstack /usr/lib/libcrypto.so.0.9.7 - /usr/lib/libcrypto.so.0.9.7 (/usr/lib/libcrypto.so.0.9.7 is "generic" library, it is written in plain C, so, compiler marks the stack as non-executable). However, optimized library have incorrect PT_GNU_STACK marking: $ execstack /usr/lib/i686/cmov/libcrypto.so.0.9.7 X /usr/lib/i686/cmov/libcrypto.so.0.9.7 Now, let's turn on soft mode (just in a case) $ sudo /bin/sh -c "echo 1 > /proc/sys/kernel/exec-shield" (turn off exec-shield, except for binaries that explicitly enable it, e.g. have PT_GNU_STACK RW-) and install glibc-2.3.5-3. $ ldd /usr/bin/ssh libresolv.so.2 => /lib/libresolv.so.2 (0x2343f000) libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x23451000) libutil.so.1 => /lib/libutil.so.1 (0x23553000) libz.so.1 => /usr/lib/libz.so.1 (0x23557000) libnsl.so.1 => /lib/libnsl.so.1 (0x2356b000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x2357f000) libselinux.so.1 => /lib/libselinux.so.1 (0x235ae000) libc.so.6 => /lib/libc.so.6 (0x235c0000) libdl.so.2 => /lib/libdl.so.2 (0x236da000) /lib/ld-linux.so.2 (0x2341e000) Now, the linker tries to use optimized library, but this library wants stack to be executable (for no good reason), so the bug (missing proper PT_GNU_STACK marker) becomes user-visible. > In any case, none of these bugs are of severity higher than important. If PaX or exec-shield (with sys.kernel.exec-shield = 3, e.g. exec-shield is always enabled) kernel is used, the system will be badly broken. Or even worse (if soft mode used, which is default with exec-shield): protection silently switched off for important binaries (e.g., ssh|sshd). So, I think 1) this is _at least_ serious bug, 2) it should have `security' tag. > There is no policy that Debian supports grsec kernels This bug can break systems using exec-shield kernels too. Moreover, there is no policy to deliberately break grsec either. Best regards, Alexei.
signature.asc
Description: Digital signature
