exec logging broken?

[devastor]

Hi,

I've encountered some wierd behaviour of exec logging with
linux 2.4.19+grsec1.9.7 and grsec1.9.7b:

~# gradm -E
grsec: Loaded grsecurity 1.9.7
~# gradm -a
Password:
grsec: successful change to admin mode by (gradm:506) UID(0) EUID(0), parent (zsh:392) UID(0) EUID(0)
~# cd /proc/sys/kernel/grsecurity
/proc/sys/kernel/grsecurity# echo 1 >> exec_logging
/proc/sys/kernel/grsecurity# cat exec_logging
<6>grsec: exec of [03:01:41841] (@u*AX>y@cat exec_logging ) by (zsh:516) UID(0) EUID(0), parent (zsh:392) UID(0) EUID(0)

/proc/sys/kernel/grsecurity# ls
grsec: exec of [03:01:42070] (`Db@l}`@ls ) by (zsh:578) UID(0) EUID(0), parent (zsh:392) UID(0) EUID(0)

This is what i get to syslog:
kernel: grsec: exec of [03:01:42070] (`D^C&#65533;&#65533;&#65533;\201&#65533;\200ls ) by (zsh:578) UID(0) EUID(0), parent (zsh:392) UID(0) EUID(0)

something obviously goes wrong and causes those wierd chars there..
here's maybe even a bigger issue:

/proc/sys/kernel/grsecurity# cat *
grsec: exec of [03:01:41841] (@s*Ap=y@cat acl altered_pings audit_chdir audit_ipc audit_moun) by (zsh:517) UID(0) EUID(0), parent (zsh:392) UID(0) EUID(0)
Unable to handle kernel paging request at virtual address ffffffff
printing eip:
ffffffff
*pde = 00001063
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<ffffffff>] Not tainted
EFLAGS: 00010212
eax: fffffff2 ebx: c0f93ef4 ecx: 0001fc80 edx: 0001fc80
esi: c0f93df0 edi: c0f93df0 ebp: 00000000 esp: c0f93f08
ds: 0018 es: 0018 ss: 0018
Process zsh (pid: 517, stackpage=c0f93000)
Stack: ffffffff ffffffff 00000023 00000018 c1151000 00000000 00000000 c0f93f44
c0107693 c1151000 22ced678 5d0a94fc c0f93f4c c0f92000 080c9c78 5d0a00cc
c0108993 5d0a019c 22ced678 5d0a94fc 080c9c78 5d0a019c 5d0a00cc 0000000b
Call Trace: [<c0107693>] [<c0108993>]

Code: Bad EIP value.
zsh: 517 segmentation fault cat *
/proc/sys/kernel/grsecurity#

Everything works fine when exec_logging is disabled.
Looks like a big bug in the exec logging code to me.
Any ideas?

--
Tuomas Silen
tuomas@silen.eu.org

[spender]

you're right, it was broken. Apparently you're the only person using the exec logging...I've released 1.9.7c which fixes the bug.

-Brad

[devastor]

great, thank you.

--
Tuomas Silen
tuomas@silen.eu.org

[devastor]

OK, i tested the new version and it works a bit better
No more wierd chars there.

Still, tho, it will cause a program to segmentation fault if I for example do
cat * when there's many files in the directory..
and I get that "Unable to handle kernel NULL pointer dereference.." to the log..

I looked at the code and _I think_ that gr_handle_exec_args() might
cause a buffer overflow: strncat(grarg, argv[i], 63 - execlen); + null char
fills grarg[64] if there's enough parameters, which is ok, but then, after the
last parameter, one space is still added there: strcat(grarg, " ");
and this will exceed the buffer and cause it to overflow..?

Increasing grarg's size to 65 should allow it to put that one last space there
and fix the problem.. I tested that and it seems to work..and programs didn't
segmentation fault anymore or anything..
But you probably should check it out.. I could be wrong, but that helped at least

Thanks

--
Tuomas Silen
tuomas@silen.eu.org

[spender]

I looked at the code and _I think_ that gr_handle_exec_args() might
cause a buffer overflow: strncat(grarg, argv[i], 63 - execlen); + null char
fills grarg[64] if there's enough parameters, which is ok, but then, after the
last parameter, one space is still added there: strcat(grarg, " ");
and this will exceed the buffer and cause it to overflow..?

strncat null terminates, so no matter how much is in the buffer, that line won't cause there to be any more than 63 charactesr in grarg (including the null). So then the space is appended, and that bumps it up to 64 (including the null). Then it goes through the loop again, and the size is of course larger than 63, so nothing more will be inserted into the buffer. I'll test the code some more, but I don't see any buffer overflow in there.
[/quote]

[spender]

could you pass the oops through ksymoops and paste the output?

-Brad

[spender]

ok, I see the problem now. Redownload the 1.9.7c patch. Only about 10 people have downloaded it, so I just replaced the copy on the server. I also made sure that at least the inode/dev of the binary being executed is logged if they pass NULL as argv.

-Brad

[devastor]

OK, so i guess you don't need ksymoops' output anymore?

--
Tuomas Silen
tuomas@silen.eu.org

[spender]

not unless you still have problems with the new version

-Brad

[devastor]

No, it works fine now