A new class of vulnerabilitieshave been identified under the umbrella name “StackSmashing”.
This bug class exploits a weakness in theaddress space model of operating systems like Linux.
How does itwork…
The programs in operatingsystems use a so called stack for storing variables and returnaddresses used in functions. The stack grows depending on the amountof variables used and the depth of the called function tree. Thegrowth direction is also special, on most platforms it growsdownwards.
As the stack shares the same address space with theregular program, heap and libraries and other program memory regionscare needs to be taken that the automatic growing stack does notcollide with other memory regions.
For this some years ago a”stack guard gap” page of 4KB was introduced, that is alsoused for automatic growing the stack if a stack memory access goesinto the guard page.
The security research company Qualys hasidentified that in some libraries and programs under specificconditions the stack pointer can “jump over” this 4KB stackguard page and proceed below it or even overwrite memory areaspositioned there.
This can for happen with large arrays on thestack over 4KB which are accessed only in some places, or by programsusing the alloca() function to getstack memory that is also not accessed fully.
This grown stackcould then be made to “smash” into other memory areas,containing code, data, function pointers or similar and which in turncould be used to execute code.
Note that these problems arenot bugs in the programs, libraries or the kernel themselves, butcaused by vague interpretation of the stack grow magic ABI betweenthe compiler and kernel.
To mitigatethis class of attacks we will be doing the following :
– LinuxKernels are being released immediately.
The kernel updates willincrease the stack gap size to be much larger (1 MB / 16 MB),which should mitigate most of the cases found during research.
Thismitigation is tracked under CVE-2017-1000364
– glibcpackages are being released immediately.
glibc itself contains severalcases of being able to effect these stack jumps, happening evenbefore a binary is loaded in the dynamic loader.
When used withsetuid root binaries these could be used to escalate privilege fromuser to root using stack smashing.
This security fix is tracked underCVE-2017-1000366
– gcc (GNUCompiler Collection) updates will be released in the near future.
These updates will feature aflag that enables touching all stack memory pages when dynamic largestack allocations are done, to avoid having large jumps.
Note thatas the stack code is directly built into the libraries and binaries, recompiling packages is necessary to make it effective.
– Variousapplications might be updated in the near future.
We will identify and releaseupdates for various applications that have such stack usage patternsand rebuild them with the new gcc compiler flag.