Dear Debian developers,
I've filled a few individual bugs[1,2,3,4] but Emilio suggested, to bring up
the topic here for effectiveness and coordination.
Triggered by a blog post[5], I started to look into some of my Debian amd64
based systems and noticed, certain binaries and libraries have an overly huge
segment alignment (2MB instead of the usual 4kB).
This was no issue until "recently", as it was basically ignored by the Linux
kernel ELF loader and the (glibc based) runtime linker. However, kernel[6] and
glibc[7] patches changed this and the ELF segment alignment will be honored by
each respectively since then (kernel ELF loader, aligning PT_LOAD entries of
binaries accordingly; runtime linker, aligning PT_LOAD entries of loaded shared
libraries).
I wrote an article[8] about the topic, providing some history and relating it
to Debian releases. Basically, all binary packages that haven't been rebuild
since stretch are prone to the over-alignment.
The over-alignment is bad, as it reduces the number of available ASLR bits and,
thereby, weakens this probabilistic mitigation, accelerating brute force
attacks.
Fortunately, it's mostly only old packages that are affected. However, some of
these are used with recent software as well (the X related libraries, for
example).
To get rid of the over-alignment, a rebuild with a linker that doesn't enforce
the overly huge alignment any more is sufficient. In Debian terms that would be
anything starting with buster.
I, thereby, request to rebuild affected packages.
Detecting if a package is affected can be done with either the script[9] we
provided along with the blog post, or by making use of readelf. For the latter
it would be to look for oddities like below:
minipli@nuc:~$ readelf -WSl /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
There are 27 section headers, starting at offset 0x5208:
Section Headers:
[Nr] Name TypeAddress OffSize ES Flg
Lk Inf Al
[ 0] NULL 00 00 00
0 0 0
[ 1] .note.gnu.build-id NOTE01c8 0001c8 24 00 A
0 0 4
[ 2] .gnu.hash GNU_HASH01f0 0001f0 000180 00 A
3 0 8
[ 3] .dynsym DYNSYM 0370 000370 000600 18 A
4 1 8
[ 4] .dynstr STRTAB 0970 000970 00041f 00 A
0 0 1
[ 5] .gnu.version VERSYM 0d90 000d90 80 02 A
3 0 2
[ 6] .gnu.version_rVERNEED 0e10 000e10 50 00 A
4 2 8
[ 7] .rela.dyn RELA0e60 000e60 c0 18 A
3 0 8
[ 8] .rela.plt RELA0f20 000f20 000258 18 AI
3 22 8
[ 9] .init PROGBITS1178 001178 17 00 AX
0 0 4
[10] .plt PROGBITS1190 001190 0001a0 10 AX
0 0 16
[11] .plt.got PROGBITS1330 001330 08 00 AX
0 0 8
[12] .text PROGBITS1340 001340 001908 00 AX
0 0 16
[13] .fini PROGBITS2c48 002c48 09 00 AX
0 0 4
[14] .rodata PROGBITS2c60 002c60 001020 00 A
0 0 32
[15] .eh_frame_hdr PROGBITS3c80 003c80 00016c 00 A
0 0 4
[16] .eh_frame PROGBITS3df0 003df0 0008d4 00 A
0 0 8
[17] .init_array INIT_ARRAY 00204de0 004de0 08 08 WA
0 0 8
[18] .fini_array FINI_ARRAY 00204de8 004de8 08 08 WA
0 0 8
[19] .jcr PROGBITS00204df0 004df0 08 00 WA
0 0 8
[20] .dynamic DYNAMIC 00204df8 004df8 0001e0 10 WA
4 0 8
[21] .got PROGBITS00204fd8 004fd8 28 08 WA
0 0 8
[22] .got.plt PROGBITS00205000 005000 e0 08 WA
0 0 8
[23] .data PROGBITS002050e0 0050e0 08 00 WA
0 0 8
[24] .bss NOBITS 002050e8 0050e8 08 00 WA
0 0 1
[25] .gnu_debuglinkPROGBITS 0050e8 34 00
0 0 1
[26] .shstrtab STRTAB 00511c ec 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
Elf file type is DYN (Shared object file)
Entry point 0x1340
There are 7 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz
Flg Align
LOAD 0x00 0x 0x 0x0046c4
0x0046c4 R E 0x20
LOAD
