User1
On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
|| User1 creates file with permissions 0644
|| User2 opens file for read access on file descriptor 4
|| User1 chmod's directory to 0700
|| User1 chmod's file to 0666
|| User1 verifies no hard links to file
|| User2 can not open the file for read or write access
|| User2 can not write to file descriptor 4
|| User2 _can_ write to /proc/$$/fd/4
On 27.10.2009 14:04, Vincent Zweije wrote:
> On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
>
> || User1 creates file with permissions 0644
> || User2 opens file for read access on file descriptor 4
> || User1 chmod's directory to 0700
> || User1 chmod's file to 0666
> || User1 verifies no hard links to file
> || User2 can not open the file for read or write access
> || User2 can not write to file descriptor 4
as expected, there's a race condition where the user could create the
hard link after the sysadmin checked, but before the permissions were
corrected. Unlikely, I know... but possible.
There's a nearly identical case that works in all Unixen, AFAIK: You
have /a/b/file1, which is writable to user1. The user has permission
to descend /a and /a/b. At some point user1 does a cd to /a/b. Then
at some later point, while the user still has that shell open, the
sysadmin closes off permission to /a, and user1 no longer can descend
it. But it doesn't matter... user1 has already got a shell open in
/a/b, and therefore full access to all the files there which are not
|| On 27.10.2009 14:04, Vincent Zweije wrote:
|| > After chmodding the directory to 0700, *first*
|| >check the link count, *then* chmod the file to 0666:
|| >
|| > User1 creates file with permissions 0644
|| > User2 opens file for read access on file descriptor 4
|| > User1 chmod's directory to 0700
|| > User1 verifies no hard links to file
||
|| Here's a window, during which User2 is able to create a hardlink
> No, you're not right.
>
> > After chmodding the directory to 0700, *first*
> >check the link count, *then* chmod the file to 0666:
> >
> > User1 creates file with permissions 0644
> > User2 opens file for read access on file descriptor 4
> > User1 chmod's directory to 0700
> > User1 verifies no hard links to file
>
> Here's a window, during which User2 is able to create a hardlink and
>>> No, you're not right.
>>>
>>>> After chmodding the directory to 0700, *first*
>>>> check the link count, *then* chmod the file to 0666:
>>>>
>>>> User1 creates file with permissions 0644
>>>> User2 opens file for read access on file descriptor 4
>>>> User1 chmod's directory to 0700
>>>> User1 verifies no hard links to file
>>>
>>> Here's a window, during which User2 is able to create a hardlink and
It was originally documented in ISSUE 14 by an anonymous author:
http://www.milw0rm.com/exploits/8880
It turns out that he was showing how a root shell can be created:
[user1@testing574 tmp]$ ls -al
total 28
drwxrwxrwt 4 root root 4096 May 21 08:41 .
drwxr-xr-x 24 root root 4096 May 19 16:57 ..
-rw-rw-r-- 1 user1 user1 0 May 21 08:40 ;cd ..;chown root.root shell;chmod 4755 shell;
drwx------ 2 root root 4096 May 21 08:41 backupPdUzR4
>> No, you're not right.
>>
>>> After chmodding the directory to 0700, *first*
>>> check the link count, *then* chmod the file to 0666:
>>>
>>> User1 creates file with permissions 0644
>>> User2 opens file for read access on file descriptor 4
>>> User1 chmod's directory to 0700
>>> User1 verifies no hard links to file
>>
>> Here's a window, during which User2 is able to create a hardlink and
Dear Dan,
You wrote:
>> User1 creates file with permissions 0644
>> User2 opens file for read access on file descriptor 4
>> User1 chmod's directory to 0700
>> User1 verifies no hard links to file
>
> Here's a window, during which User2 is able to create a hardlink and that will
no links.
Pavel wrote his email in a convoluted way, so it's not clear what's going
on. Here's an attempt to rewrite:
User1 creates file with permissions 0644
User2 opens file for read access on file descriptor 4
User1 chmod's directory to 0700
User1 chmod's file to 0666
User1 verifies no hard links to file
User2 can not open the file for read or write access
$ mkdir foo
$ cd foo
$ echo hi > bar
$ ls -la
total 12
drwxr-xr-x 2 user1 group1 4096 2009-10-27 16:22 ./
drwx------ 57 user1 group1 4096 2009-10-27 16:22 ../
-rw-r--r-- 1 user1 group1 3 2009-10-27 16:22 bar
$ chmod 000 .
$ echo bye > bar
-bash: bar: Permission denied
> $ mkdir foo
> $ cd foo
> $ echo hi > bar
> $ ls -la
> total 12
> drwxr-xr-x 2 user1 group1 4096 2009-10-27 16:22 ./
> drwx------ 57 user1 group1 4096 2009-10-27 16:22 ../
> -rw-r--r-- 1 user1 group1 3 2009-10-27 16:22 bar
> $ chmod 000 .
> $ echo bye > bar
> -bash: bar: Permission denied
- The universe of salts for htpasswd is far less than the MD5 algorithm
provides for -- 29 bits vs. 48, or 0.000191 percent of the range that
should be used for MD5.
- Any passwords encrypted by htpasswd within the same second of
system clock time will have the same salt, e.g.
$ htpasswd -nbm user1 pass1; htpasswd -nbm user2 pass2; \
htpasswd -nbm user3 pass2
user1:$apr1$7jv93/..$2J9qu4mN2zms5O42vw/XE.
user2:$apr1$7jv93/..$55cRqVaWTSB1YQpeD5uYe0
user3:$apr1$7jv93/..$55cRqVaWTSB1YQpeD5uYe0
All three users have the same salt, "7jv93/..", and user2 and user3
|
