Vulnerable Systems:
* Linux kernel 2.6.39 rc4 and prior
Local attackers can exploit this issue to obtain sensitive information that may lead to further attacks.
The overwrite is triggered when executables with special names handled by binfmt_script call each other until BINPRM_MAX_RECURSION is reached. During each round, load_script from fs/binfmt_script.c extracts the interpreter name for the next round and stores it within the current stack frame. The pointer to this name is also copied to bprm->interp and used during execution of the next interpreter (also a script) within search_binary_handler function. This is not problematic unless CONFIG_MODULES is also defined. When BINPRM_MAX_RECURSION is reached, load_script returns, thus leaving bprm->interp pointing to a now non-existing stack frame. Due to CONFIG_MODULES and the special interpreter name, search_binary_handler will trigger request for loading of module via request_module and invoke load_script again. The function will then append the data from dangling pointer bprm->interp to exec args, thus disclosing some kernel stack bytes. Output on 64-bit system might co
0000170: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
0000180: 4141 4141 2d35 3600 7878 7800 ffff ffff AAAA-56.xxx.....
0000190: ffff ff7f ffff ffff ffff ff7f 809a ac1d ................
00001a0: 0078 7878 000d 6669 6c65 2d41 4141 4141 .xxx..file-AAAAA
00001b0: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
Apart from memory disclosure, reaching BINPRM_MAX_RECURSION will not terminate execve call with error, but invocation of load_script is triggered more than the intended maximum of loader invocations, leading to higher CPU consumption from single call to execve.
Disclosure Timeline:
20120818: Discovery, triggered discussion about patch on lkml
20120902: Kernel.org bugreport, perhaps someone might pck it up from there.
20120920: Tried to restart discussion again on lkml
20121011: Kees Cook restarted on lkml: binfmt_script: do not leave interp on stack
20121019: CVE assigned: CVE-2012-4530 (see oss-security)
