grsecurity forums

Hi,

I think, I've found a bug or incompatibility in the ACL subsystem of grsecurity
(grsecurity-2.1.1-2.4.29-200501231159 as well a grsecurity-2.1.1-2.6.10-as2-200501242254).

Please try the following steps:

1. Enable the ACLs.

2. Create a ZIP file in a directory where you have read/write permission (e.g. /tmp):

touch acl_test.txt
zip acl_test.zip acl_test.txt

3. Unpack acl_test.zip with unzip (Info-ZIP UnZip 5.51):

rm acl_test.txt
unzip acl_test.zip

The unzip command failed on my machine with the message

error: cannot create acl_test.txt

and

grsec: (default:D:/) denied create of /tmp/acl_test.txt for writing by /usr/bin/unzip[unzip:23108] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:4279] uid/euid:0/0 gid/egid:0/0

was logged.

4. Disable the ACLs and repeat step 3. Everything works as expected now.

To be sure that there is something wrong in grsecurity and it is not a bug in my policy file, I've tried it with the policy.sample which is bundled with gradm-2.1.1.
The described behaviour can be reproduced with that policy, too.
If the object flags of /tmp are set to rwcdlx, the problem occurs also.

By the way: Using tar instead of zip/unzip still works fine.

-vs

Can you provide me with the output of strace on the unzip command? I'm not able to duplicate the problem you're having.

-Brad

Hi,

thanks for your patient assistance - I think I've got the solution.

Here is the relevant part of the strace log (ACLs enabled):

open("test_unzip.txt", O_WRONLY|O_CREAT|O_LARGEFILE, 01001626270) = -1 EACCES (Permission denied)
fcntl64(-1, F_GETFL) = -1 EBADF (Bad file descriptor)
ioctl(1, TIOCGWINSZ, {ws_row=24, ws_col=139, ws_xpixel=1272, ws_ypixel=364}) = 0
write(2, "error: cannot create test_unzip"..., 37) = 37

The filemode argument of open() looks strange.

I'm using the Fedora Core package unzip-5.51-4.src.rpm which contains a patch
named unzip-5.51-near-4GB.patch. Since you couldn't duplicate
problem, I've recompiled unzip without this patch and unzip works fine:

open("test_unzip.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
ioctl(1, TIOCGWINSZ, {ws_row=24, ws_col=139, ws_xpixel=1272, ws_ypixel=364}) = 0
write(1, " extracting: test_unzip.txt "..., 37) = 37
close(5) = 0
utime("test_unzip.txt", [2005/02/22-22:08:40, 2005/02/22-22:08:40]) = 0
chmod("test_unzip.txt", 0100644) = 0

unzip-5.51-near-4GB.patch contains

Code: Select all

diff -ur unzip-5.51/fileio.c unzip-5.51-lhh/fileio.c
@@ -413,7 +424,9 @@
 #endif /* NOVELL_BUG_FAILSAFE */
     Trace((stderr, "open_outfile:  doing fopen(%s) for writing\n",
       FnFilter1(G.filename)));
-    if ((G.outfile = fopen(G.filename, FOPW)) == (FILE *)NULL) {
+   
+    fd = open(G.filename, O_WRONLY | O_LARGEFILE | O_CREAT);
+    if ((G.outfile = fdopen(fd, FOPW)) == (FILE *)NULL) {
         Info(slide, 0x401, ((char *)slide, LoadFarString(CannotCreateFile),
           FnFilter1(G.filename)));
         return 1;

Note, that open() is called without the filemode argument. This caused
the problem.

Changing

Code: Select all

fd = open(G.filename, O_WRONLY | O_LARGEFILE | O_CREAT);

to

Code: Select all

fd = open(G.filename, O_WRONLY | O_LARGEFILE | O_CREAT, S_IRWXU);

fixed it.

-vs

That's what I figured the problem was. We've seen it with other broken apps as well. I would imagine this kind of bug could also be exploitable. Even if the file was chmodded later, there's a race condition there, and in the case you were seeing, the app was getting its suid/sgid bit set. With the right timing and a trojaned zip file, you should be able to get a rootshell out of the deal.

-Brad