+-- On Sat, 24 Nov 2012, Kees Cook wrote --+
| Well, "ever" meaning "if depth is hit, always fail out", yes. This is
| intentional. We do not want to attempt module loading if we hit a recursion
| limit.
Ah yes, that's right!
Thanks so much! :)
--
Prasad J Pandit / Red Hat Security Response T
P J P wrote:
>
>Hello Kees, all,
>
> Please have a look at a *NEW* patch at the end of this mail. It seems to fix
> both the issues, stack disclosure + undue recursions.
>
> It uses modprobe "--first-time" option which returns an error code when
> trying
> to load a module which is alread
Hello Kees, all,
Please have a look at a *NEW* patch at the end of this mail. It seems to fix
both the issues, stack disclosure + undue recursions.
It uses modprobe "--first-time" option which returns an error code when trying
to load a module which is already present or unload one which is
+-- On Mon, 19 Nov 2012, Kees Cook wrote --+
| I think to avoid the explosion of request_module calls in the abusive
| case, we could simply return ELOOP instead of ENOEXEC on max
| recursion.
-> http://www.spinics.net/lists/mm-commits/msg92433.html
1. returning -ELOOP has a side effect of not r
+-- On Mon, 19 Nov 2012, Linus Torvalds wrote --+
| isn't your patch the one that does a request_module even without trying
| without it? There was a discussion about why that isn't valid. Don't do it.
Yep, okay.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939
+-- 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 needi
On Sun, Nov 18, 2012 at 10:57 PM, P J P wrote:
> +-- On Sun, 18 Nov 2012, Kees Cook wrote --+
> | This is the second problem. I view this as less critical because it's only
> | 64 instead of 4, but it certainly should be solved as well.
>
> I don't mean to be rude, but the patch I had sent solve
+-- On Sun, 18 Nov 2012, Kees Cook wrote --+
| This is the second problem. I view this as less critical because it's only
| 64 instead of 4, but it certainly should be solved as well.
I don't mean to be rude, but the patch I had sent solves both of these
problems with much less performance hit
On Sun, Nov 18, 2012 at 11:04 AM, P J P wrote:
> +-- On Fri, 16 Nov 2012, Kees Cook wrote --+
> | Hrm? It should be showing only the live heap-allocated interp -- are
> | you seeing uninitialized contents?
>
> I don't see uninitialised content; I see interpreter names from previous
> iterations.
+-- On Fri, 16 Nov 2012, Kees Cook wrote --+
| Hrm? It should be showing only the live heap-allocated interp -- are
| you seeing uninitialized contents?
I don't see uninitialised content; I see interpreter names from previous
iterations. Which was the case earlier as well. The - interp - array i
On Fri, Nov 16, 2012 at 4:50 AM, P J P wrote:
>
> Hello folks,
>
> +-- On Mon, 12 Nov 2012, Kees Cook wrote --+
> | > Al, what's your take on the *rare* extra call to request_module?
> |
> | Without any other feedback, I'd like to use my minimal allocation
> | patch, since it fixes the problem
Hello folks,
+-- On Mon, 12 Nov 2012, Kees Cook wrote --+
| > Al, what's your take on the *rare* extra call to request_module?
|
| Without any other feedback, I'd like to use my minimal allocation
| patch, since it fixes the problem and doesn't change any of the
| semantics of how/when loadi
If a series of scripts are executed, each triggering module loading via
unprintable bytes in the script header, kernel stack contents can leak
into the command line.
Normally execution of binfmt_script and binfmt_misc happens
recursively. However, when modules are enabled, and unprintable bytes
ex
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kees Cook wrote:
> On Tue, Nov 6, 2012 at 12:10 AM, P J P wrote:
>>
>> Hello Kees, Al,
>>
>> +-- On Sat, 27 Oct 2012, Kees Cook wrote --+ | If we change
>> binfmt_script to not make a recursive call, then we still | need
>> to keep the interp change
On Tue, Nov 6, 2012 at 12:10 AM, P J P wrote:
>
> Hello Kees, Al,
>
> +-- On Sat, 27 Oct 2012, Kees Cook wrote --+
> | If we change binfmt_script to not make a recursive call, then we still
> | need to keep the interp change somewhere off the stack. I still think
> | my patchset is the least bad
Hello Kees, Al,
+-- On Sat, 27 Oct 2012, Kees Cook wrote --+
| If we change binfmt_script to not make a recursive call, then we still
| need to keep the interp change somewhere off the stack. I still think
| my patchset is the least bad.
|
| Al, do you have something else in mind?
Guys, are
On Sat, Oct 27, 2012 at 1:16 PM, P J P wrote:
> +-- On Sat, 27 Oct 2012, Kees Cook wrote --+
> | Al showed a list of them earlier in the thread.
>
> Yeah, the list Al showed and I came across mostly has - binfmt_aout - entry.
> Do people still use - a.out - format? (considering ELF has been the
+-- On Sat, 27 Oct 2012, Kees Cook wrote --+
| Al showed a list of them earlier in the thread.
Yeah, the list Al showed and I came across mostly has - binfmt_aout - entry.
Do people still use - a.out - format? (considering ELF has been the default
standard for so many years)
| I don't have an
On Sat, Oct 27, 2012 at 3:47 AM, P J P wrote:
> +-- On Fri, 26 Oct 2012, Al Viro wrote --+
> | > not. Module alias could dodge this though, I guess.
> | "Could"? Can you show a single module that would have name matching
> | binfmt-[0-9a-f]*? In other words, are they ever loaded _not_ via an
> |
+-- On Fri, 26 Oct 2012, Al Viro wrote --+
| > not. Module alias could dodge this though, I guess.
| "Could"? Can you show a single module that would have name matching
| binfmt-[0-9a-f]*? In other words, are they ever loaded _not_ via an
| alias?
I understand. I was wondering if alias informa
On Fri, Oct 26, 2012 at 11:08:20PM +0530, P J P wrote:
> +-- On Thu, 25 Oct 2012, Al Viro wrote --+
> | * every bleeding script will have bogus execution of modprobe done
> | at execve time (and you'd better pray that /sbin/modprobe isn't a shell
> | script wrapper around the actual binary, or
+-- On Thu, 25 Oct 2012, Al Viro wrote --+
| * every bleeding script will have bogus execution of modprobe done
| at execve time (and you'd better pray that /sbin/modprobe isn't a shell
| script wrapper around the actual binary, or you *will* get loop prevention
| kick in)
| * none of t
Hello Tetsuo,
+-- On Thu, 25 Oct 2012, Tetsuo Handa wrote --+
| Excuse me, but why do you change definition of printable(c) ?
| Looks like a regression.
#define printable(c) (((c)=='\t') || ((c)=='\n') || (0x20<=(c) && (c)<=0x7e))
Earlier definition of printable() as above was used to - bre
On Thu, Oct 25, 2012 at 01:09:53PM +0100, Al Viro wrote:
> On Thu, Oct 25, 2012 at 05:16:22PM +0530, P J P wrote:
> >
> > Hello Kees,
> >
> > +-- On Wed, 24 Oct 2012, Kees Cook wrote --+
> > | What should the code here _actually_ be doing? The _script and _misc
> > | handlers expect to rewrite
On Thu, Oct 25, 2012 at 05:16:22PM +0530, P J P wrote:
>
> Hello Kees,
>
> +-- On Wed, 24 Oct 2012, Kees Cook wrote --+
> | What should the code here _actually_ be doing? The _script and _misc
> | handlers expect to rewrite the bprm contents and recurse, but the module
> | loader want to try
P J P wrote:
>
> Hello Kees,
>
> +-- On Wed, 24 Oct 2012, Kees Cook wrote --+
> | What should the code here _actually_ be doing? The _script and _misc
> | handlers expect to rewrite the bprm contents and recurse, but the module
> | loader want to try again. It's not clear to me what the binfm
Hello Kees,
+-- On Wed, 24 Oct 2012, Kees Cook wrote --+
| What should the code here _actually_ be doing? The _script and _misc
| handlers expect to rewrite the bprm contents and recurse, but the module
| loader want to try again. It's not clear to me what the binfmt module
| handler is even
On Wed, Oct 24, 2012 at 9:16 PM, Al Viro wrote:
> On Wed, Oct 24, 2012 at 04:20:32PM -0700, Kees Cook wrote:
>> If a series of scripts are executed, each triggering module loading via
>> unprintable bytes in the script header, kernel stack contents can leak
>> into the command line.
>>
>> Normally
On Wed, Oct 24, 2012 at 04:20:32PM -0700, Kees Cook wrote:
> If a series of scripts are executed, each triggering module loading via
> unprintable bytes in the script header, kernel stack contents can leak
> into the command line.
>
> Normally execution of binfmt_script and binfmt_misc happens
> r
If a series of scripts are executed, each triggering module loading via
unprintable bytes in the script header, kernel stack contents can leak
into the command line.
Normally execution of binfmt_script and binfmt_misc happens
recursively. However, when modules are enabled, and unprintable bytes
ex
30 matches
Mail list logo
