Search for patch for kernel stack disclosure in binfmt_script during execve
Subsystems (2)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm searching for a patch for linux kernel stack disclosure in binfmt_script with crafted interpreter names when CONFIG_MODULES is active (see [1]).
The simplest solution would be to return an error in load_script (from fs/binfmt_script.c). when maximal recursion depth is reached, but I'm not sure, if that is nice and could have any side effects. Apart from that, some change in the loop condition in search_binary_handler (from fs/exec.c) could have side effects hard to see and hence reintroduce the bug (challenge to get that right in documentation).
Any comments?
- --- fs/binfmt_script.c 2012-01-19 23:04:48.000000000 +0000
+++ fs/binfmt_script.c 2012-08-18 13:55:25.735748407 +0000
@@ -22,9 +22,8 @@
char interp[BINPRM_BUF_SIZE];
int retval;- - if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!') ||
- - (bprm->recursion_depth > BINPRM_MAX_RECURSION))
- - return -ENOEXEC;
+ if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!')) return
- -ENOEXEC;
+ if (bprm->recursion_depth > BINPRM_MAX_RECURSION) return -ENOMEM;
/*
* This section does the #! interpretation.
* Sorta complicated, but hopefully it will work. -TYT
hd
[1]
http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/
- --
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlAvn0MACgkQxFmThv7tq+6nUACfdk7KWESuC6J1FXZcrMaa3kCb eWoAn0wV6INdYGjAZydd6ytO0i5BnhGa
=cxbR
-----END PGP SIGNATURE-----
Re: Search for patch for kernel stack data disclosure in binfmt_script during execve
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · halfdog
I'm searching for a patch for linux kernel stack disclosure in
binfmt_scriptwith crafted interpreter names whenCONFIG_MODULESis active (see [1]).
Please disregard my previous proposal [2], since it did not address the problem directly (referencing local stack frame data from bprm structure) but worked around it. I suspect, that this could increase probability to reintroduce similar bugs.
Opinions on (untested sketch for) second solution: Could someone look on the source code comments and changes in patch to judge, if this is going in the right direction?
Explanation of patch: Since load_script will start to irreversibly change bprm structures at some point (using stack local data was one of those changes), try to delay this point. Run checks if load_script could be the right handler, if not give other binfmt handlers the chance to do so.
If binfmt_script is the right one, try to load the interpreter (causing bprm modification), if failing make sure that no other binfmt handler has the chance to continue on the now modified bprm data.
CAVEAT: This assumes, that if binfmt_script could handle the load, that it would be the one and only binfmt with that ability, so no other one, e.g. binfmt_misc should have the chance to do so. If this assumption is wrong, leaving binfmt_script would have to rollback all bprm changes (e.g. restore old credentials).
hd
[1]
http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/
[2] http://lkml.org/lkml/2012/8/18/75
- --
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlAwphsACgkQxFmThv7tq+6UAQCgh7IA8UcqNieV41YKHS5/YxGE IbcAn1uP1nIakg/gD1KlV0KNnLIfitEp
=5Klt
-----END PGP SIGNATURE-----
binfmt_script.c +82 -28
@@ -14,12 +14,24 @@#include <linux/err.h> #include <linux/fs.h> +/** Check if this handler is suitable to load the "binary" identified +* by first BINPRM_BUF_SIZE bytes in bprm->buf. +* @returns -ENOEXEC if this handler is not suitable for that type +* of binary. In that case, the handler must not modify any of the +* data associated with bprm. +* Any error if the binary should have been handled by this loader +* but handling failed. In that case. FIXME: be defensive? also +* kill bprm->mm or bprm->file also to make it impossible, that +* upper search_binary_handler can continue handling? +* 0 (OK) otherwise, the new executable is ready in bprm->mm. +*/ static int load_script (struct linux_binprm *bprm,struct pt_regs *regs) {const char *i_arg, *i_name;char *cp;struct file *file; -char interp[BINPRM_BUF_SIZE ]; +char bprm_buf_copy[BINPRM_BUF_SIZE ]; +char *bprm_old_interp_name;int retval; if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!') ||
@@ -30,25 +42,29 @@ static int load_script(struct linux_binp* Sorta complicated, but hopefully it will work. -TYT */ - bprm->recursion_depth++; -allow_write_access (bprm->file); -fput (bprm->file); - bprm->file =NULL ; +/* Keep bprm unchanged until we known, that this is a script +* to be handled by this loader. Copy bprm->buf for sure, +* otherwise returning -ENOEXEC will make other handlers see +* modified data. (hd) +*/ +memcpy (bprm_buf_copy, bprm->buf,BINPRM_BUF_SIZE ); - bprm->buf[BINPRM_BUF_SIZE -1 ] ='\0' ; -if ((cp =strchr (bprm->buf,'\n' )) ==NULL ) - cp = bprm->buf+BINPRM_BUF_SIZE -1 ; + bprm_buf_copy[BINPRM_BUF_SIZE -1 ]='\0' ; +if ((cp =strchr (bprm_buf_copy,'\n' )) ==NULL ) + cp = bprm_buf_copy+BINPRM_BUF_SIZE -1 ; *cp ='\0' ; -while (cp > bprm->buf) { +while (cp > bprm_buf_copy) { cp--;if ((*cp ==' ' ) || (*cp =='\t' )) *cp ='\0' ;else break ; } -for (cp = bprm->buf+2 ; (*cp ==' ' ) || (*cp =='\t' ); cp++); +for (cp = bprm_buf_copy+2 ; (*cp ==' ' ) || (*cp =='\t' ); cp++);if (*cp =='\0' ) -return -ENOEXEC ;/* No interpreter name found */ +/* No interpreter name found. No problem to let other handlers +* retry, we did not change anything. */ +return -ENOEXEC ; i_name = cp; i_arg =NULL ;for ( ; *cp && (*cp !=' ' ) && (*cp !='\t' ); cp++)
@@ -57,45 +73,83 @@ static int load_script(struct linux_binp *cp++ ='\0' ;if (*cp) i_arg = cp; -strcpy (interp, i_name); + +/* So this is our point-of-no-return: modification of bprm +* will be irreversible, so if we fail to setup execution +* using the new interpreter name (i_name), we have to make +* sure, that no other handler tries again. (hd) +*/ +/* * OK, we've parsed out the interpreter name and * (optional) argument. * Splice in (1) the interpreter's name for argv[0] -* (2) (optional) argument to interpreter -* (3) filename of shell script (replace argv[0]) +* (2) (optional) argument to interpreter +* (3) filename of shell script (replace argv[0]) * * This is done in reverse order, because of how the * user environment and arguments are stored. */ + +/* Ugly: we store pointer to local stack frame in bprm, +* so make sure to clear this up before returning. +*/ + bprm_old_interp_name = bprm->interp; + bprm->interp = i_name; + retval =remove_arg_zero (bprm); -if (retval) -return retval; - retval =copy_strings_kernel (1 , &bprm->interp, bprm); -if (retval <0 )return retval; +if (retval) goto out; +/* copy_strings_kernel is ok here, even when racy: since no +* user can be attached to new mm, there is nobody to race +* with and call is safe for now. And copy_strings_kernel +* cannot return -ENOEXEC in any case. (hd) +*/ + retval =copy_strings_kernel (1 , &bprm_old_interp_name, bprm); +if (retval <0 ) goto out; bprm->argc++;if (i_arg) { retval =copy_strings_kernel (1 , &i_arg, bprm); -if (retval <0 )return retval; +if (retval <0 ) goto out; bprm->argc++; } - retval =copy_strings_kernel (1 , &i_name, bprm); -if (retval)return retval; + retval =copy_strings_kernel (1 , &bprm->interp, bprm); +if (retval) goto out; bprm->argc++; - bprm->interp = interp;/* * OK, now restart the process with the interpreter's dentry. +* Release old file first */ - file =open_exec (interp); -if (IS_ERR (file)) -return PTR_ERR (file); - +allow_write_access (bprm->file); +fput (bprm->file); + bprm->file =NULL ; + file =open_exec (bprm->interp); +if (IS_ERR (file)) { + retval=PTR_ERR (file); + goto out; + } bprm->file = file; +/* Caveat: This also updates the credentials of the next exec. */ retval =prepare_binprm (bprm);if (retval <0 ) -return retval; -return search_binary_handler (bprm,regs); + goto out; + bprm->recursion_depth++; + retval=search_binary_handler (bprm,regs); + +out:/* Make sure, we do not return local stack frame data. If +* it would be needed after returning, we would have needed +* to allocate memory or use copy from new bprm->mm anyway. (hd) +*/ + bprm->interp = bprm_old_interp_name; +if (!retval) { +/* The handlers for starting of interpreter failed. +* bprm is already modified, hence we are dead here. +* Make sure, that we do not return -ENOEXEC, that would +* allow searching for handlers to continue. (hd). +*/ +if (retval==-ENOEXEC ) retval=-EINVAL ; + } +return (retval); }static struct linux_binfmt script_format = {
Re: Search for patch for kernel stack data disclosure in binfmt_script during execve
Got a hint via IRC, that I should not send patch idea for review to "generic" list, but to maintainers and last (or relevant) comitters of code.
CC to generic just for the records
Quoted 38 lines · halfdog
Quoted 3 lines · halfdog
I'm searching for a patch for linux kernel stack disclosure in
binfmt_scriptwith crafted interpreter names whenCONFIG_MODULESis active (see [1]).Please disregard my previous proposal [2], since it did not address the problem directly (referencing local stack frame data from bprm structure) but worked around it. I suspect, that this could increase probability to reintroduce similar bugs.
Opinions on (untested sketch for) second solution: Could someone look on the source code comments and changes in patch to judge, if this is going in the right direction?
Explanation of patch: Since
load_scriptwill start to irreversibly change bprm structures at some point (using stack local data was one of those changes), try to delay this point. Run checks ifload_scriptcould be the right handler, if not give other binfmt handlers the chance to do so.If
binfmt_scriptis the right one, try to load the interpreter (causing bprm modification), if failing make sure that no other binfmt handler has the chance to continue on the now modified bprm data.CAVEAT: This assumes, that if
binfmt_scriptcould handle the load, that it would be the one and only binfmt with that ability, so no other one, e.g.binfmt_miscshould have the chance to do so. If this assumption is wrong, leavingbinfmt_scriptwould have to rollback all bprm changes (e.g. restore old credentials).hd
[1]
http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/
[2] http://lkml.org/lkml/2012/8/18/75
Signature · 2 lines
http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
Re: Search for patch for kernel stack data disclosure in binfmt_script during execve
Quoted 44 lines · halfdog
Got a hint via IRC, that I should not send patch idea for review to "generic" list, but to maintainers and last (or relevant) comitters of code.
CC to generic just for the records
Quoted 36 lines · halfdog
Quoted 3 lines · halfdog
I'm searching for a patch for linux kernel stack disclosure in
binfmt_scriptwith crafted interpreter names whenCONFIG_MODULESis active (see [1]).Please disregard my previous proposal [2], since it did not address the problem directly (referencing local stack frame data from bprm structure) but worked around it. I suspect, that this could increase probability to reintroduce similar bugs.
Opinions on (untested sketch for) second solution: Could someone look on the source code comments and changes in patch to judge, if this is going in the right direction?
Explanation of patch: Since
load_scriptwill start to irreversibly change bprm structures at some point (using stack local data was one of those changes), try to delay this point. Run checks ifload_scriptcould be the right handler, if not give other binfmt handlers the chance to do so.If
binfmt_scriptis the right one, try to load the interpreter (causing bprm modification), if failing make sure that no other binfmt handler has the chance to continue on the now modified bprm data.CAVEAT: This assumes, that if
binfmt_scriptcould handle the load, that it would be the one and only binfmt with that ability, so no other one, e.g.binfmt_miscshould have the chance to do so. If this assumption is wrong, leavingbinfmt_scriptwould have to rollback all bprm changes (e.g. restore old credentials).hd
[1]
http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/
[2] http://lkml.org/lkml/2012/8/18/75
What about (untested):
fs/exec.c +2 -1
@@ -1438,7 +1438,8 @@ int search_binary_handler(struct linux_binprm *bprm,struct pt_regs *regs) }read_unlock (&binfmt_lock);#ifdef CONFIG_MODULES -if (retval != -ENOEXEC || bprm->mm ==NULL ) { +if (retval != -ENOEXEC || bprm->mm ==NULL || + bprm->recursion_depth >BINPRM_MAX_RECURSION ) {break ; }else {#define printable (c) (((c)=='\t') || ((c)=='\n') || (0x20<=(c) && (c)<=0x7e))
Signature · 1 line
Kirill A. Shutemov
Re: Search for patch for kernel stack data disclosure in binfmt_script during execve
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 8 lines · Kirill A. Shutemov
Quoted 7 lines · halfdog
Got a hint via IRC, that I should not send patch idea for review to "generic" list, but to maintainers and last (or relevant) comitters of code.
...
Quoted 34 lines
Quoted 34 lines
Quoted 33 lines · halfdog
Quoted 3 lines · halfdog
I'm searching for a patch for linux kernel stack disclosure in
binfmt_scriptwith crafted interpreter names whenCONFIG_MODULESis active (see [1]).Please disregard my previous proposal [2], since it did not address the problem directly (referencing local stack frame data from bprm structure) but worked around it. I suspect, that this could increase probability to reintroduce similar bugs.
Opinions on (untested sketch for) second solution: Could someone look on the source code comments and changes in patch to judge, if this is going in the right direction?
Explanation of patch: Since
load_scriptwill start to irreversibly change bprm structures at some point (using stack local data was one of those changes), try to delay this point. Run checks ifload_scriptcould be the right handler, if not give other binfmt handlers the chance to do so.If
binfmt_scriptis the right one, try to load the interpreter
(causing bprm modification), if failing make sure that no
other binfmt handler has the chance to continue on the now modified bprm data.CAVEAT: This assumes, that if
binfmt_scriptcould handle the load, that it would be the one and only binfmt with that ability, so no other one, e.g.binfmt_miscshould have the chance to do so. If this assumption is wrong, leavingbinfmt_scriptwould have to rollback all bprm changes (e.g. restore old credentials).
Quoted 4 lines
Quoted 4 lines
[2] http://lkml.org/lkml/2012/8/18/75
Quoted 11 lines
What about (untested):
fs/exec.c index 574cf4d..ef13850 100644 renamed from fs/exec.c +0
-1--- a/fs/exec.c +++ b/fs/exec.c @@ -1438,7 +1438,8 @@ intsearch_binary_handler(struct
linux_binprm*bprm,structpt_regs
*regs) }read_unlock(&binfmt_lock); #ifdefCONFIG_MODULES- if
(retval !=-ENOEXEC||bprm->mm== NULL) { + if (retval !=-ENOEXEC||bprm->mm== NULL || +bprm->recursion_depth>BINPRM_MAX_RECURSION) { break; } else { #define printable(c) (((c)=='\t') || ((c)=='\n') || (0x20<=(c) && (c)<=0x7e))
- - From my understanding, this patch should not fix the problem, since recursion depth is reset back to old value after call of binfmt handler. This is done, so that fs/exec does not have to trust all binfmts to reset the depth by themselfes when leaving.
1408 read_unlock(&binfmt_lock); 1409 retval = fn(bprm, regs); 1410 /*
1411 * Restore the depth counter to its
starting value
1412 * in this call, so we don't have to
rely on every
1413 * load_binary function to restore it on
return.
1414 */
1415 bprm->recursion_depth = depth;
I guess, the problem is, that recursion_depth usually not only limits the depth, but also the maximal number of binfmt_xxx calls. That's why, the use of local stack-frame data in bprm does not matter, there is no going up the stack AND using bprm->interpreter, the last error is terminates the search.
In the POC, search is not terminated because of ENOEXEC when max depth reached and due to special filename, mod-loader triggers also (about 30 times? I do not known, if that could be a problem also, interfering with other module loads. Usually non-root users cannot trigger rapid module loads easily).
- --
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlA3U3QACgkQxFmThv7tq+7hTgCZAcQFn70FUWnAhvoMYhm8EcFT 8vQAn06VtbeY5P0cPGd9fcxL6AaEF8oS
=An9g
-----END PGP SIGNATURE-----
PATCH 1/1 Fix kernel stack data disclosure in binfmt_script during execve
Quoted 86 lines · halfdog
Quoted 8 lines · Kirill A. Shutemov
Quoted 7 lines · halfdog
Got a hint via IRC, that I should not send patch idea for review to "generic" list, but to maintainers and last (or relevant) comitters of code.
...
Quoted 34 lines
Quoted 34 lines
Quoted 33 lines · halfdog
Quoted 3 lines · halfdog
I'm searching for a patch for linux kernel stack disclosure in
binfmt_scriptwith crafted interpreter names whenCONFIG_MODULESis active (see [1]).Please disregard my previous proposal [2], since it did not address the problem directly (referencing local stack frame data from bprm structure) but worked around it. I suspect, that this could increase probability to reintroduce similar bugs.
Opinions on (untested sketch for) second solution: Could someone look on the source code comments and changes in patch to judge, if this is going in the right direction?
Explanation of patch: Since
load_scriptwill start to irreversibly change bprm structures at some point (using stack local data was one of those changes), try to delay this point. Run checks ifload_scriptcould be the right handler, if not give other binfmt handlers the chance to do so.If
binfmt_scriptis the right one, try to load the interpreter
(causing bprm modification), if failing make sure that no
other binfmt handler has the chance to continue on the now modified bprm data.CAVEAT: This assumes, that if
binfmt_scriptcould handle the load, that it would be the one and only binfmt with that ability, so no other one, e.g.binfmt_miscshould have the chance to do so. If this assumption is wrong, leavingbinfmt_scriptwould have to rollback all bprm changes (e.g. restore old credentials).Quoted 4 lines
Quoted 4 lines
[2] http://lkml.org/lkml/2012/8/18/75
Quoted 10 lines
What about (untested):
fs/exec.c index 574cf4d..ef13850 100644 renamed from fs/exec.c +0
-1--- a/fs/exec.c +++ b/fs/exec.c @@ -1438,7 +1438,8 @@ intsearch_binary_handler(struct
linux_binprm*bprm,structpt_regs
*regs) }read_unlock(&binfmt_lock); #ifdefCONFIG_MODULES- if
(retval !=-ENOEXEC||bprm->mm== NULL) { + if (retval !=-ENOEXEC||bprm->mm== NULL || +bprm->recursion_depth>BINPRM_MAX_RECURSION) { break; } else { #define printable(c) (((c)=='\t') || ((c)=='\n') || (0x20<=(c) && (c)<=0x7e))- From my understanding, this patch should not fix the problem, since recursion depth is reset back to old value after call of binfmt handler. This is done, so that fs/exec does not have to trust all binfmts to reset the depth by themselfes when leaving.
1408 read_unlock(&binfmt_lock); 1409 retval = fn(bprm, regs); 1410 /*1411 * Restore the depth counter to its
starting value
1412 * in this call, so we don't have to
rely on every
1413 *load_binaryfunction to restore it on
return.
1414 */
1415bprm->recursion_depth= depth;I guess, the problem is, that
recursion_depthusually not only limits the depth, but also the maximal number ofbinfmt_xxxcalls. That's why, the use of local stack-frame data in bprm does not matter, there is no going up the stack AND usingbprm->interpreter, the last error is terminates the search.
Quoted 7 lines
In the POC, search is not terminated because of ENOEXEC when max depth reached and due to special filename, mod-loader triggers also (about 30 times? I do not known, if that could be a problem also, interfering with other module loads. Usually non-root users cannot trigger rapid module loads easily).
Quoted 1 line
What about (untested):
Now this is the updated and also tested patch (vs. linux-3.5.4 kernel) to fix
https://bugzilla.kernel.org/show_bug.cgi?id=46841 . See also
http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/
This patch adresses the stack data disclosure but does not deal with the excessive recursion (to be handled in separate patch if needed).
binfmt_script.c +83 -28
@@ -14,12 +14,24 @@#include <linux/err.h> #include <linux/fs.h> +/** Check if this handler is suitable to load the "binary" identified +* by first BINPRM_BUF_SIZE bytes in bprm->buf. +* @returns -ENOEXEC if this handler is not suitable for that type +* of binary. In that case, the handler must not modify any of the +* data associated with bprm. +* Any error if the binary should have been handled by this loader +* but handling failed. In that case. FIXME: be defensive? also +* kill bprm->mm or bprm->file also to make it impossible, that +* upper search_binary_handler can continue handling? +* 0 (OK) otherwise, the new executable is ready in bprm->mm. +*/ static int load_script (struct linux_binprm *bprm,struct pt_regs *regs) {const char *i_arg, *i_name;char *cp;struct file *file; -char interp[BINPRM_BUF_SIZE ]; +char bprm_buf_copy[BINPRM_BUF_SIZE ]; +const char *bprm_old_interp_name;int retval; if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!') ||
@@ -30,25 +42,29 @@ static int load_script(struct linux_binp* Sorta complicated, but hopefully it will work. -TYT */ - bprm->recursion_depth++; -allow_write_access (bprm->file); -fput (bprm->file); - bprm->file =NULL ; +/* Keep bprm unchanged until we known, that this is a script +* to be handled by this loader. Copy bprm->buf for sure, +* otherwise returning -ENOEXEC will make other handlers see +* modified data. (hd) +*/ +memcpy (bprm_buf_copy, bprm->buf,BINPRM_BUF_SIZE ); - bprm->buf[BINPRM_BUF_SIZE -1 ] ='\0' ; -if ((cp =strchr (bprm->buf,'\n' )) ==NULL ) - cp = bprm->buf+BINPRM_BUF_SIZE -1 ; + bprm_buf_copy[BINPRM_BUF_SIZE -1 ]='\0' ; +if ((cp =strchr (bprm_buf_copy,'\n' )) ==NULL ) + cp = bprm_buf_copy+BINPRM_BUF_SIZE -1 ; *cp ='\0' ; -while (cp > bprm->buf) { +while (cp > bprm_buf_copy) { cp--;if ((*cp ==' ' ) || (*cp =='\t' )) *cp ='\0' ;else break ; } -for (cp = bprm->buf+2 ; (*cp ==' ' ) || (*cp =='\t' ); cp++); +for (cp = bprm_buf_copy+2 ; (*cp ==' ' ) || (*cp =='\t' ); cp++);if (*cp =='\0' ) -return -ENOEXEC ;/* No interpreter name found */ +/* No interpreter name found. No problem to let other handlers +* retry, we did not change anything. */ +return -ENOEXEC ; i_name = cp; i_arg =NULL ;for ( ; *cp && (*cp !=' ' ) && (*cp !='\t' ); cp++)
@@ -57,45 +73,84 @@ static int load_script(struct linux_binp *cp++ ='\0' ;if (*cp) i_arg = cp; -strcpy (interp, i_name); + +/* So this is our point-of-no-return: modification of bprm +* will be irreversible, so if we fail to setup execution +* using the new interpreter name (i_name), we have to make +* sure, that no other handler tries again. (hd) +*/ +/* * OK, we've parsed out the interpreter name and * (optional) argument. * Splice in (1) the interpreter's name for argv[0] -* (2) (optional) argument to interpreter -* (3) filename of shell script (replace argv[0]) +* (2) (optional) argument to interpreter +* (3) filename of shell script (replace argv[0]) * * This is done in reverse order, because of how the * user environment and arguments are stored. */ + +/* Ugly: we store pointer to local stack frame in bprm, +* so make sure to clear this up before returning. +*/ + bprm_old_interp_name = bprm->interp; + bprm->interp = i_name; + retval =remove_arg_zero (bprm); -if (retval) -return retval; - retval =copy_strings_kernel (1 , &bprm->interp, bprm); -if (retval <0 )return retval; +if (retval) goto out; +/* copy_strings_kernel is ok here, even when racy: since no +* user can be attached to new mm, there is nobody to race +* with and call is safe for now. The return code of +* copy_strings_kernel cannot be -ENOEXEC in any case, +* so no special checks needed. (hd) +*/ + retval =copy_strings_kernel (1 , &bprm_old_interp_name, bprm); +if (retval <0 ) goto out; bprm->argc++;if (i_arg) { retval =copy_strings_kernel (1 , &i_arg, bprm); -if (retval <0 )return retval; +if (retval <0 ) goto out; bprm->argc++; } - retval =copy_strings_kernel (1 , &i_name, bprm); -if (retval)return retval; + retval =copy_strings_kernel (1 , &bprm->interp, bprm); +if (retval) goto out; bprm->argc++; - bprm->interp = interp;/* * OK, now restart the process with the interpreter's dentry. +* Release old file first */ - file =open_exec (interp); -if (IS_ERR (file)) -return PTR_ERR (file); - +allow_write_access (bprm->file); +fput (bprm->file); + bprm->file =NULL ; + file =open_exec (bprm->interp); +if (IS_ERR (file)) { + retval=PTR_ERR (file); + goto out; + } bprm->file = file; +/* Caveat: This also updates the credentials of the next exec. */ retval =prepare_binprm (bprm);if (retval <0 ) -return retval; -return search_binary_handler (bprm,regs); + goto out; + bprm->recursion_depth++; + retval=search_binary_handler (bprm,regs); + +out:/* Make sure, we do not return local stack frame data. If +* it would be needed after returning, we would have needed +* to allocate memory or use copy from new bprm->mm anyway. (hd) +*/ + bprm->interp = bprm_old_interp_name; +if (!retval) { +/* The handlers for starting of interpreter failed. +* bprm is already modified, hence we are dead here. +* Make sure, that we do not return -ENOEXEC, that would +* allow searching for handlers to continue. (hd). +*/ +if (retval==-ENOEXEC ) retval=-EINVAL ; + } +return (retval); }static struct linux_binfmt script_format = {
Signature · 2 lines
http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
Re: [PATCH] Fix kernel stack data disclosure in binfmt_script during execve
binfmt_script.c
Quoted 10 lines · halfdog
halfdog wrote:
Now this is the updated and also tested patch (vs. linux-3.5.4 kernel) to fix
https://bugzilla.kernel.org/show_bug.cgi?id=46841 . See also
http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/
This patch adresses the stack data disclosure but does not deal with the excessive recursion (to be handled in separate patch if needed).binfmt_script.c +0
-0
Incorrect diff/patch format for kernel patches.
It should be apply-able by using 'patch -p1'.
Oh, the patch is not signed off.
And Documentation/SubmittingPatches says signoffs are:
"using your real name (sorry, no pseudonyms or anonymous contributions.)"
There are also some kernel coding style issues that should be fixed if this patch is to be merged.
binfmt_script.c line 17
Quoted 5 lines
binfmt_script.c +1
-0@@ -14,12 +14,24 @@#include <linux/err.h> #include <linux/fs.h> +/** Check if this handler is suitable to load the "binary" identified
/** means kernel-doc notation in the kernel, but this comment block is not kernel-doc, so don't start it with /**
binfmt_script.c line 19
Quoted 2 lines
binfmt_script.c +2
-0+* by first BINPRM_BUF_SIZE bytes in bprm->buf. +* @returns -ENOEXEC if this handler is not suitable for that type
We don't use "@returns", just returns: <text>.
Quoted 22 lines
binfmt_script.c +10
-1+* of binary. In that case, the handler must not modify any of the +* data associated with bprm. +* Any error if the binary should have been handled by this loader +* but handling failed. In that case. FIXME: be defensive? also +* kill bprm->mm or bprm->file also to make it impossible, that +* upper search_binary_handler can continue handling? +* 0 (OK) otherwise, the new executable is ready in bprm->mm. +*/ static int load_script (struct linux_binprm *bprm,struct pt_regs *regs) {const char *i_arg, *i_name;char *cp;struct file *file; -char interp[BINPRM_BUF_SIZE ]; +char bprm_buf_copy[BINPRM_BUF_SIZE ]; +const char *bprm_old_interp_name;int retval; if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!') ||@@ -30,25 +42,29 @@ static int load_script(struct linux_binp* Sorta complicated, but hopefully it will work. -TYT */
binfmt_script.c static int load_script(struct linux_binp · line 49
Quoted 10 lines
binfmt_script.c +5
-4- bprm->recursion_depth++; -allow_write_access (bprm->file); -fput (bprm->file); - bprm->file =NULL ; +/* Keep bprm unchanged until we known, that this is a script +* to be handled by this loader. Copy bprm->buf for sure, +* otherwise returning -ENOEXEC will make other handlers see +* modified data. (hd) +*/
Kernel multi-line comment style is
/* * line 1 * line 2 */
Quoted 13 lines
binfmt_script.c +5
-4+memcpy (bprm_buf_copy, bprm->buf,BINPRM_BUF_SIZE ); - bprm->buf[BINPRM_BUF_SIZE -1 ] ='\0' ; -if ((cp =strchr (bprm->buf,'\n' )) ==NULL ) - cp = bprm->buf+BINPRM_BUF_SIZE -1 ; + bprm_buf_copy[BINPRM_BUF_SIZE -1 ]='\0' ; +if ((cp =strchr (bprm_buf_copy,'\n' )) ==NULL ) + cp = bprm_buf_copy+BINPRM_BUF_SIZE -1 ; *cp ='\0' ; -while (cp > bprm->buf) { +while (cp > bprm_buf_copy) { cp--;if ((*cp ==' ' ) || (*cp =='\t' ))
binfmt_script.c static int load_script(struct linux_binp · line 66
Quoted 10 lines
binfmt_script.c +3
-2*cp ='\0' ; else break; } -for (cp = bprm->buf+2 ; (*cp ==' ' ) || (*cp =='\t' ); cp++); +for (cp = bprm_buf_copy+2 ; (*cp ==' ' ) || (*cp =='\t' ); cp++);if (*cp =='\0' ) -return -ENOEXEC ;/* No interpreter name found */ +/* No interpreter name found. No problem to let other handlers +* retry, we did not change anything. */
multi-line comment style.
Quoted 5 lines
binfmt_script.c +1
-0+return -ENOEXEC ; i_name = cp; i_arg =NULL ;for ( ; *cp && (*cp !=' ' ) && (*cp !='\t' ); cp++)
binfmt_script.c static int load_script(struct linux_binp · line 81
Quoted 10 lines
binfmt_script.c +6
-1@@ -57,45 +73,84 @@ static int load_script(struct linux_binp *cp++ ='\0' ;if (*cp) i_arg = cp; -strcpy (interp, i_name); + +/* So this is our point-of-no-return: modification of bprm +* will be irreversible, so if we fail to setup execution +* using the new interpreter name (i_name), we have to make +* sure, that no other handler tries again. (hd) +*/
ditto.
Quoted 7 lines
binfmt_script.c +1
-2+/* * OK, we've parsed out the interpreter name and * (optional) argument. * Splice in (1) the interpreter's name for argv[0] -* (2) (optional) argument to interpreter -* (3) filename of shell script (replace argv[0])
binfmt_script.c static int load_script(struct linux_binp · line 96
Quoted 10 lines
binfmt_script.c +6
-0+* (2) (optional) argument to interpreter +* (3) filename of shell script (replace argv[0]) * * This is done in reverse order, because of how the * user environment and arguments are stored. */ + +/* Ugly: we store pointer to local stack frame in bprm, +* so make sure to clear this up before returning. +*/
ditto.
binfmt_script.c static int load_script(struct linux_binp · line 101
Quoted 9 lines
binfmt_script.c +4
-4+ bprm_old_interp_name = bprm->interp; + bprm->interp = i_name; + retval =remove_arg_zero (bprm); -if (retval) -return retval; - retval =copy_strings_kernel (1 , &bprm->interp, bprm); -if (retval <0 )return retval; +if (retval) goto out;
Really should be
if (retval) goto out;
binfmt_script.c static int load_script(struct linux_binp · line 107
Quoted 6 lines
binfmt_script.c +6
-0+/* copy_strings_kernel is ok here, even when racy: since no +* user can be attached to new mm, there is nobody to race +* with and call is safe for now. The return code of +* copy_strings_kernel cannot be -ENOEXEC in any case, +* so no special checks needed. (hd) +*/
style.
binfmt_script.c static int load_script(struct linux_binp · line 113
Quoted 7 lines
binfmt_script.c +3
-1+ retval =copy_strings_kernel (1 , &bprm_old_interp_name, bprm); +if (retval <0 ) goto out; bprm->argc++;if (i_arg) { retval =copy_strings_kernel (1 , &i_arg, bprm); -if (retval <0 )return retval; +if (retval <0 ) goto out;
style.
binfmt_script.c static int load_script(struct linux_binp · line 117
Quoted 6 lines
binfmt_script.c +2
-2bprm->argc++; } - retval =copy_strings_kernel (1 , &i_name, bprm); -if (retval)return retval; + retval =copy_strings_kernel (1 , &bprm->interp, bprm); +if (retval) goto out;
style. (but Al can override these if he wants to)
binfmt_script.c static int load_script(struct linux_binp · line 122
Quoted 6 lines
binfmt_script.c +1
-1bprm->argc++; - bprm->interp = interp;/* * OK, now restart the process with the interpreter's dentry. +* Release old file first
indentation mucked up.
Quoted 17 lines
binfmt_script.c +9
-4*/ - file =open_exec (interp); -if (IS_ERR (file)) -return PTR_ERR (file); - +allow_write_access (bprm->file); +fput (bprm->file); + bprm->file =NULL ; + file =open_exec (bprm->interp); +if (IS_ERR (file)) { + retval=PTR_ERR (file); + goto out; + } bprm->file = file; +/* Caveat: This also updates the credentials of the next exec. */ retval =prepare_binprm (bprm);if (retval <0 )
binfmt_script.c static int load_script(struct linux_binp · line 143
Quoted 10 lines
binfmt_script.c +8
-2-return retval; -return search_binary_handler (bprm,regs); + goto out; + bprm->recursion_depth++; + retval=search_binary_handler (bprm,regs); + +out:/* Make sure, we do not return local stack frame data. If +* it would be needed after returning, we would have needed +* to allocate memory or use copy from new bprm->mm anyway. (hd) +*/
Comment block probably should come before the label. and the indentation is mucked up.
binfmt_script.c static int load_script(struct linux_binp · line 150
Quoted 7 lines
binfmt_script.c +7
-0+ bprm->interp = bprm_old_interp_name; +if (!retval) { +/* The handlers for starting of interpreter failed. +* bprm is already modified, hence we are dead here. +* Make sure, that we do not return -ENOEXEC, that would +* allow searching for handlers to continue. (hd). +*/
style
binfmt_script.c static int load_script(struct linux_binp · line 151
Quoted 1 line
binfmt_script.c +1
-0+if (retval==-ENOEXEC ) retval=-EINVAL ;
missing space before '('.
etc.
Quoted 6 lines
binfmt_script.c +2
-0+ } +return (retval); }static struct linux_binfmt script_format = {
Signature · 1 line
~Randy
Re: [PATCH v2] Fix kernel stack data disclosure in binfmt_script during execve
Quoted 10 lines · Randy Dunlap
Quoted 8 lines · halfdog
halfdog wrote:
Now this is the updated and also tested patch (vs. linux-3.5.4 kernel) to fix
https://bugzilla.kernel.org/show_bug.cgi?id=46841 . See also
http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/
This patch adresses the stack data disclosure but does not deal with the excessive recursion (to be handled in separate patch if needed).
Quoted 7 lines
binfmt_script.c
Quoted 2 lines
binfmt_script.c +0
-0Incorrect diff/patch format for kernel patches.
It should be apply-able by using 'patch -p1'.
...
OK, formatting changed:
* patch depth level added
* comment style changed
* goto-s now on own line
Has any one looked at the logic apart from the styling? Are there any flaws?
Quoted 1 line
Oh, the patch is not signed off.
Yes. Anyone who likes it can sign it off or even resubmit it in his name.
fs/binfmt_script.c +96 -27
@@ -14,12 +14,25 @@#include <linux/err.h> #include <linux/fs.h> +/* +* Check if this handler is suitable to load the "binary" identified +* by first BINPRM_BUF_SIZE bytes in bprm->buf. +* returns: -ENOEXEC if this handler is not suitable for that type +* of binary. In that case, the handler must not modify any of the +* data associated with bprm. +* Any error if the binary should have been handled by this loader +* but handling failed. In that case. FIXME: be defensive? also +* kill bprm->mm or bprm->file also to make it impossible, that +* upper search_binary_handler can continue handling? +* 0 (OK) otherwise, the new executable is ready in bprm->mm. +*/ static int load_script (struct linux_binprm *bprm,struct pt_regs *regs) {const char *i_arg, *i_name;char *cp;struct file *file; -char interp[BINPRM_BUF_SIZE ]; +char bprm_buf_copy[BINPRM_BUF_SIZE ]; +const char *bprm_old_interp_name;int retval; if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!') ||
@@ -30,25 +43,32 @@ static int load_script(struct linux_binp* Sorta complicated, but hopefully it will work. -TYT */ - bprm->recursion_depth++; -allow_write_access (bprm->file); -fput (bprm->file); - bprm->file =NULL ; +/* +* Keep bprm unchanged until we known, that this is a script +* to be handled by this loader. Copy bprm->buf for sure, +* otherwise returning -ENOEXEC will make other handlers see +* modified data. (hd) +*/ +memcpy (bprm_buf_copy, bprm->buf,BINPRM_BUF_SIZE ); - bprm->buf[BINPRM_BUF_SIZE -1 ] ='\0' ; -if ((cp =strchr (bprm->buf,'\n' )) ==NULL ) - cp = bprm->buf+BINPRM_BUF_SIZE -1 ; + bprm_buf_copy[BINPRM_BUF_SIZE -1 ]='\0' ; +if ((cp =strchr (bprm_buf_copy,'\n' )) ==NULL ) + cp = bprm_buf_copy+BINPRM_BUF_SIZE -1 ; *cp ='\0' ; -while (cp > bprm->buf) { +while (cp > bprm_buf_copy) { cp--;if ((*cp ==' ' ) || (*cp =='\t' )) *cp ='\0' ;else break ; } -for (cp = bprm->buf+2 ; (*cp ==' ' ) || (*cp =='\t' ); cp++); +for (cp = bprm_buf_copy+2 ; (*cp ==' ' ) || (*cp =='\t' ); cp++);if (*cp =='\0' ) -return -ENOEXEC ;/* No interpreter name found */ +/* +* No interpreter name found. No problem to let other handlers +* retry, we did not change anything. +*/ +return -ENOEXEC ; i_name = cp; i_arg =NULL ;for ( ; *cp && (*cp !=' ' ) && (*cp !='\t' ); cp++)
@@ -57,45 +77,94 @@ static int load_script(struct linux_binp *cp++ ='\0' ;if (*cp) i_arg = cp; -strcpy (interp, i_name); + +/* +* So this is our point-of-no-return: modification of bprm +* will be irreversible, so if we fail to setup execution +* using the new interpreter name (i_name), we have to make +* sure, that no other handler tries again. (hd) +*/ +/* * OK, we've parsed out the interpreter name and * (optional) argument. * Splice in (1) the interpreter's name for argv[0] -* (2) (optional) argument to interpreter -* (3) filename of shell script (replace argv[0]) +* (2) (optional) argument to interpreter +* (3) filename of shell script (replace argv[0]) * * This is done in reverse order, because of how the * user environment and arguments are stored. */ + +/* +* Ugly: we store pointer to local stack frame in bprm, +* so make sure to clear this up before returning. +*/ + bprm_old_interp_name = bprm->interp; + bprm->interp = i_name; + retval =remove_arg_zero (bprm);if (retval) -return retval; - retval =copy_strings_kernel (1 , &bprm->interp, bprm); -if (retval <0 )return retval; + goto out; +/* +* copy_strings_kernel is ok here, even when racy: since no +* user can be attached to new mm, there is nobody to race +* with and call is safe for now. The return code of +* copy_strings_kernel cannot be -ENOEXEC in any case, +* so no special checks needed. (hd) +*/ + retval =copy_strings_kernel (1 , &bprm_old_interp_name, bprm); +if (retval <0 ) + goto out; bprm->argc++;if (i_arg) { retval =copy_strings_kernel (1 , &i_arg, bprm); -if (retval <0 )return retval; +if (retval <0 ) + goto out; bprm->argc++; } - retval =copy_strings_kernel (1 , &i_name, bprm); -if (retval)return retval; + retval =copy_strings_kernel (1 , &bprm->interp, bprm); +if (retval) + goto out; bprm->argc++; - bprm->interp = interp;/* * OK, now restart the process with the interpreter's dentry. +* Release old file first */ - file =open_exec (interp); -if (IS_ERR (file)) -return PTR_ERR (file); - +allow_write_access (bprm->file); +fput (bprm->file); + bprm->file =NULL ; + file =open_exec (bprm->interp); +if (IS_ERR (file)) { + retval=PTR_ERR (file); + goto out; + } bprm->file = file; +/* Caveat: This also updates the credentials of the next exec. */ retval =prepare_binprm (bprm);if (retval <0 ) -return retval; -return search_binary_handler (bprm,regs); + goto out; + bprm->recursion_depth++; + retval=search_binary_handler (bprm,regs); + +/* +* Make sure, we do not return local stack frame data. If +* it would be needed after returning, we would have needed +* to allocate memory or use copy from new bprm->mm anyway. (hd) +*/ +out: + bprm->interp = bprm_old_interp_name; +if (!retval) { +/* +* The handlers for starting of interpreter failed. +* bprm is already modified, hence we are dead here. +* Make sure, that we do not return -ENOEXEC, that would +* allow searching for handlers to continue. (hd). +*/ +if (retval==-ENOEXEC ) retval=-EINVAL ; + } +return (retval); }static struct linux_binfmt script_format = {
---
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee