+-- On Mon, 19 Nov 2012, Kees Cook wrote --+ | I don't think you're being rude at all. You're defending your solution. :)
Thank you Kees, really appreciate it. | However, it also changes the conditions for when a module is loaded | (i.e. 0x7f no longer triggers a module_load, so anything needing that | would break -- I'm not sure if this really qualifies for ABI breakage, | I don't use any obscure binfmt modules so I can't say). Ah right. | And, most importantly, it triggers request_module for any binary with | unprintables that binfmt_misc may already handle (for example, the | very common case of handling DOS MZ files, which only define 2 bytes | as magic (MZ) and exampes I find show things like "@\x00" trailing it, | or JAR files which are PK\x03\x04). Which means each exec of these | kinds of files would trigger a needless request_module() call on every | exec. Hmmn...true. | Both the interp-on-heap patch and this proposed ELOOP patch are needed | to handle the case of binfmt_script and/or binfmt_misc being modules | (first binfmt walk fails with -ENOEXEC, loads binfmt_script, retries | loop, hits binfmt_script rewriting interp to a PE file, recurses, | fails with -ENOEXEC, loads binfmt_misc via a modalias for PE files, | retries loop, hits binfmt_misc rewriting interp to an ELF, recurses, | loads ELF, happiness). Without the heap patch, we could be pointing | into old stack (rewritten e.g. during module load or taking an | interrupt, etc) on the loop retries. Without the ELOOP patch, the | recursion could explode with an abusive script chain. I see! Thanks so much for explaining Kees, I appreciate it. Thank you. -- Prasad J Pandit / Red Hat Security Response Team DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
