Next Page >>
chmodding
$ cat cow
moo
$ echo meow >/proc/self/fd/3
$ cat cow
meow
$ chmod 400 cow
$ echo moo >/proc/self/fd/3
bash: /proc/self/fd/3: Permission denied
$ ll
total 24
4 drwx------ 2 ap users 4096 2009-10-29 08:51 .
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
> || User2 _can_ write to /proc/$$/fd/4
On Tue, Oct 27, 2009 at 08:09:57PM +0300, Dan Yefimov wrote:
|| 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
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
> >That race is easily fixed.
>
> 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
> pavel@toy:/tmp$ uname -a
> Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux
> pavel@toy:/tmp mkdir my_priv; cd my_priv
> pavel@toy:/tmp/my_priv$ echo this file should never be writable> unwritable_file
> # lock down directory
> pavel@toy:/tmp/my_priv$ chmod 700 .
> # relax file permissions, directory is private, so this is safe
> # check link count on unwritable_file. We would not want someone
> # to have a hard link to work around our permissions, would we?
> pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
> pavel@toy:/tmp/my_priv$ cat unwritable_file
pavel & guest: cd /tmp
pavel: mkdir my_priv; cd my_priv
pavel: echo this file should never be writable > unwritable_file
guest: mkdir pirate_chest
guest: ln my_priv/unwritable_file pirate_chest
pavel: chmod 700 .
pavel: chmod 666 unwritable_file
pavel: cat unwritable_file
guest: echo got you > pirate_chest/unwritable_file
pavel: cat unwritable_file
> On 29.10.2009 0:27, Pavel Machek wrote:
>>>> That race is easily fixed.
>>>
>>> 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
On 29.10.2009 0:27, Pavel Machek wrote:
>>> That race is easily fixed.
>>
>> 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
pavel@toy:/tmp$ uname -a
Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux
pavel@toy:/tmp mkdir my_priv; cd my_priv
pavel@toy:/tmp/my_priv$ echo this file should never be writable > unwritable_file
# lock down directory
pavel@toy:/tmp/my_priv$ chmod 700 .
# relax file permissions, directory is private, so this is safe
# check link count on unwritable_file. We would not want someone
# to have a hard link to work around our permissions, would we?
pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
pavel@toy:/tmp/my_priv$ cat unwritable_file
Create a subdirectory under /tmp or /var/tmp to work from.
For example adding:
mkdir /var/tmp/plink
chmod 700 /var/tmp/plink
Second Vulnerability:
The script rebootTask contains the following lines for HP-UX Shutdown and reboot:
On 24.10.2009 2:39, Pavel Machek wrote:
>>> Original owner did chmod 666... after making sure traditional unix
>>> permissions protect the file. Please look at original mail; it was
>>> subtle but I believe I got it right, and file would not be writable
>>> with /proc unmounted.
>>>
>> I remember the original mail content. You're right, you can't reach
>> the file if the procfs is not mounted, but you forget about the
>> race, allowing the guest to create a hardlink to the file in an
>> unrestricted location before the directory access becomes
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
> remain unnoticed by User1. There's no way to perform link check and
> conditionally do chmod in an atomic manner.
Pavel Machek wrote:
> Check it again. There's no race; I check link count before chmod 666.
Which creates a race condition, as the link could be created after the
check but before the chmod.
You can't safely rely upon directory permissions if the directory was
created 0777 then chmod'ed down later. It needs to be created with the
On Friday 23 October 2009 23:39:24 Pavel Machek wrote:
> Check it again. There's no race; I check link count before chmod 666.
And between checking the link count and the chmod?
IV. Workaround
Set the permissions on the freebsd-update(8) working directory to not
allow unprivileged users to read said directory:
# chmod 0700 /var/db/freebsd-update
Note that if freebsd-update(8) is run using the '-d workdir' option, the
directory which should have its permissions adjusted will be different.
V. Solution
pwd
Example 3:
ftp://192.168.11.143//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////site chmod 777 .
The situation, can be dangerous, when this bug will be exploited like any CSRF attack. We can use SITE CHMOD command to change file permission or other combinations with ftp commands. Only we need some exploit and luck, that admin will executed exploited url.
How to exploit it?
> >pavel@toy:/tmp/my_priv$ chmod 700 .
> ># relax file permissions, directory is private, so this is safe
> ># check link count on unwritable_file. We would not want someone
> ># to have a hard link to work around our permissions, would we?
> >pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
> >pavel@toy:/tmp/my_priv$ cat unwritable_file
> >this file should never be writable
> >pavel@toy:/tmp/my_priv$ cat unwritable_file
> >got you
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
User2 can not write to file descriptor 4
User2 _can_ write to /proc/$$/fd/4
> that or not. If you didn't in fact restrict an access to the file,
> you're on your own.
Now... go back to my original email:
%pavel@toy:/tmp/my_priv$ chmod 700 .
%# relax file permissions, directory is private, so this is safe
%# check link count on unwritable_file. We would not want someone
%# to have a hard link to work around our permissions, would we?
%pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
> >Original owner did chmod 666... after making sure traditional unix
> >permissions protect the file. Please look at original mail; it was
> >subtle but I believe I got it right, and file would not be writable
> >with /proc unmounted.
> >
> I remember the original mail content. You're right, you can't reach
> the file if the procfs is not mounted, but you forget about the
> race, allowing the guest to create a hardlink to the file in an
> unrestricted location before the directory access becomes
> restricted. Again, procfs is just another, specific kind of
>> On 24.10.2009 0:35, Matthew Bergin wrote:
>> >doesnt look like the original owner is trying to write to it. Shows it
>> >cant, it had guest write to it via the proc folders bad permissions.
>> >Looks legitimate
>> >
>> Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an
>> attacker? No, that was the owner of 'unwritable_file', nobody else.
>> What the 0666 file mode means? It means, that everybody can write to
>> the file, can't he? So why do you believe that pretension
>> legitimate?
>
Attacker opens my_priv and waits.
>pavel@toy:/tmp/my_priv$ echo this file should never be writable > unwritable_file
># lock down directory
>pavel@toy:/tmp/my_priv$ chmod 700 .
># relax file permissions, directory is private, so this is safe
># check link count on unwritable_file. We would not want someone
># to have a hard link to work around our permissions, would we?
>pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
>pavel@toy:/tmp/my_priv$ cat unwritable_file
sysadmins to check and test their systems.
I used an Ubuntu/Debian (IA32) system which *I had to make vulnerable on
purpose*. The tweaks were:
- - #1: make the spool writable to attacker
chmod o+w /var/mail
- - #2: disable mail aliases (LDA should be able to deliver mail directly to
"root" mailbox)
- - #3: use "local" postfix process as LDA
Perhaps condition #1 is the most difficult to meet, for a normal
On Mon 2009-10-26 16:05:18, Tamber Penketh wrote:
> On Friday 23 October 2009 23:39:24 Pavel Machek wrote:
>
> > Check it again. There's no race; I check link count before chmod 666.
> And between checking the link count and the chmod?
At that point directory permissions will already disallow any changes.
Pavel
> $ 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
I think that fails because you've removed the search bits from the dir so
bash no longer has permissions to -find- the file. Eg:
On 24.10.2009 1:56, Pavel Machek wrote:
> Now... go back to my original email:
>
> %pavel@toy:/tmp/my_priv$ chmod 700 .
> %# relax file permissions, directory is private, so this is safe
> %# check link count on unwritable_file. We would not want someone
> %# to have a hard link to work around our permissions, would we?
> %pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
>
> Yes, you are right, open file descriptor acts as a kind of hardlink
> On 24.10.2009 0:35, Matthew Bergin wrote:
> >doesnt look like the original owner is trying to write to it. Shows it
> >cant, it had guest write to it via the proc folders bad permissions.
> >Looks legitimate
> >
> Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an
> attacker? No, that was the owner of 'unwritable_file', nobody else.
> What the 0666 file mode means? It means, that everybody can write to
> the file, can't he? So why do you believe that pretension
> legitimate?
>> On 24.10.2009 0:35, Matthew Bergin wrote:
>>> doesnt look like the original owner is trying to write to it. Shows it
>>> cant, it had guest write to it via the proc folders bad permissions.
>>> Looks legitimate
>>>
>> Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an
>> attacker? No, that was the owner of 'unwritable_file', nobody else.
>> What the 0666 file mode means? It means, that everybody can write to
>> the file, can't he? So why do you believe that pretension
>> legitimate?
>
127# du /home/
4 /home/cxib/.ssh
Segmentation fault (core dumped)
127# rm -rf Samotnosc
Segmentation fault (core dumped)
127# chmod -R 000 Samotnosc
Segmentation fault (core dumped)
127# gdb -q du
(no debugging symbols found)
Next Page>>
|
