Next Page >>
File Permissions
| Microsoft Windows Dial-Up | including | |
| Networking Interface | 4.8.02.0010 | |
|-----------------------------+------------------+---------------|
| 2. Local Privilege | All versions up | CSCsj00785 |
| Escalation Through Default | to but not | |
| cvpnd.exe File Permissions | including | |
| | 5.0.01.0600 | |
+----------------------------------------------------------------+
Note: The VPN Client for Windows software is distributed as both a
Microsoft Installer (MSI) package and an InstallShield (IS) package. Only
> > IMHO; no bug or security issue, just a misunderstanding of the
> > mechanism...
Correct. It is a completely flawed assumption.
In Unix, an open() of a file checks access permissions as
specified in the files inode. If someone wants access control
applied to a file, then he MUST do so using the permission in
the file inode.
Making assumptions about directory search and acces permissions
rather the file descriptor. There is a missing check in /proc that tests
the file descriptor to see if it's ro, wo (or possible rw) and, instead,
it only checks the inode info on the file. Since the fd is the intervening
resources, a check should be done to see what it allows. The check for the
inode permissions are more questionable. As can be seen above, using a fd
directly ignores file permissions and only uses fd "permissions". Accessing
via /proc is like accessing via fd so there is an argument to be had for
keeping semantics the same (then again, there's an argument to be had
for listening to file system permissions since that's also the context it's
in).
other. Successful exploitation of these vulnerabilities may result in
unauthorized system or host operating system access.
This security advisory identifies the following vulnerabilities:
* ACE Device Manager and ANM invalid directory permissions
vulnerability
* ANM default user credentials vulnerability
* ANM MySQL default credentials vulnerability
* ANM Java agent privilege escalation
psz@maths.usyd.edu.au wrote:
> > According to POSIX, if you open the directory with O_SEARCH then openat()
> > does not re-check search (+x) permissions.
>
> My 2.6.26 kernel (or Debian lenny) does not seem to know about O_SEARCH.
> But anyway... even if openat() does not re-check permissions, it should
> surely fail when in fact it does not have permissions? Surely, directory
> contents are not cached? Or, do you have an example (of a running OS)
I repeat: Show me how to gain write access without using /proc, and
I'll agree with you.
(To recap:
While file permissions allow writing, directory permissions do not
allow any access at all.
guest has open file descriptor for reading.
Trouble is that guest can upgrade file descriptor to one that allows
>
By using hardlinks, as you were already told by two different persons.
> (To recap:
>
> While file permissions allow writing, directory permissions do not
> allow any access at all.
>
> guest has open file descriptor for reading.
>
> Trouble is that guest can upgrade file descriptor to one that allows
>>>> Just looked more carefully at fs/proc/base.c. That behavior is due
>>>> to proc_fd_info() called from proc_fd_link() obtains file->f_path,
>>>> that in turn contains the reference to the open file dentry and
>>>> hence inode. That's exactly why those symlinks behave as hardlinks.
>>>> This behavior assumes, that if you were able to open the file,
>>>> you've all necessary transition permissions to access it's inode.
>>>> But in order to follow them you need privileges to read the process
>>>> memory, which hardly restricts the impact of this behavior. I don't
>>>> think this should be fixed, since /proc/<PID>/fd/ is mainly for
>>>> debugging purposes.
>>>
Avast! Professional Edition <= 4.8.1356
Avast! Home Edition <= 4.8.1356
DETAILS
Avast! installs some program files with insecure permissions. "Everyone" group has "Full Control" rights to the files/folders in the following path: "%Program Files%\Alwil Software\Avast4\Data". Its mean that any unprivileged user can modify, delete or change permissions of any file in DATA folder. The folder consists of data, executable and configuration files. In result multiple attack vectors are possible.
Vulnerability #1 Local privilege escalation (CVE-2009-3524)
A local attacker (unprivileged user) can modify %Program Files%\Alwil Software\Avast4\Data\avast4.ini file. "ISAPIFilter1" parameter in avast4.ini contains filename or full path to ISAPI filter module – originally "ashWsFtr.dll". An attacker can replace the original path by path to the attackers malicious dynamic library (DLL). After restart attackers DLL will be loaded with SYSTEM privileges. This is local privilege escalation vulnerability.
* When a remote site attempts to access a local resource, Internet
Explorer will fail to enforce the Zone Elevation restrictions.
* When browsing a remote site, Internet Explorer will not apply the
right Security Zone permissions, allowing a site belonging to a less
secure zone to be treated as one belonging to a more privileged zone.
*Vulnerable Packages*
That said, the user in the example already has access to the file (in
a running process), and would be able to do so again, *if he had
access to a directory where the file was hard-linked*. Pavel
described that the sysadmin checked for that, but even if this worked
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
> 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
> this file should never be writable
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
this file should never be writable
necessary for creating and deleting the file (which changes the contents
of the directory), but not for writing to the file.
In fact, not even read access on the directory is necessary. Traverse (x)
access on the directory is enough to get to the file (inode, actually);
after that, the file permissions determine what you can do to the file's
contents.
Ciao. Vincent.
--
Vincent Zweije <zweije@xs4all.nl> | "If you're flamed in a group you
>> be lot of C code. Feel free to play, my example was not nearly the
>> only way to demonstrate it, and no, it was not racy.
>
> Here is an example that shows the behavior where a passed read-only fd
> can become read-write by reopening it through /proc, when file
> permissions allow it (but directory permissions do not):
>
> $ sudo su
> # mkdir -m 0700 /dir
> # echo "safe" > /dir/file.txt
> # chmod 0666 /dir/file.txt
> -----Original Message-----
> From: nomail@nomail.com [mailto:nomail@nomail.com]
> Sent: Monday, October 26, 2009 9:15 AM
> To: bugtraq@securityfocus.com
> Subject: Re: Re: /proc filesystem allows bypassing directory
> permissions on Linux
>
> >> I do not think mounting /proc should change access control
> semantics.
> >>
> >It didn't in fact change anything. If the guest created
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
>this file should never be writable
On 24.10.2009 10:47, Anton Ivanov wrote:
> Following your logic we should all abandon directory permissions and
> stick to file-only ones. Hmm... Dunno, probably the blood level in my
> coffee subsystem is too high this morning, but I do not quite relish
> that idea.
>
I didn't affirm that. I only told, that directory permissions can't in fact
restrict access to the file it contains, they can only hamper accessing that
file via that directory.
=============================================================================
FreeBSD-SA-09:17.freebsd-update Security Advisory
The FreeBSD Project
Topic: Inappropriate directory permissions in freebsd-update(8)
Category: core
Module: usr.sbin
Announced: 2009-12-03
Credits: KAMADA Ken'ichi
webserver, the new files and directories will be created based on the
active umask. In most cases, this will give read & write access to
the owner of the files and read access for all other users.
Since FWS needs to write to certain files and directories, the
instructions in the manual tell you to specifically set file permissions
on a specific set of files and directories. For files, the owner, group
and world are all given read & write permissions including the file
settings.inc.php. For directories the execute bit is also set. The file
settings.inc.php contains the database username and password. In case
of a shared hosting environment, this allows for local user to obtain
Also not affected are the following configurations: a) maildir-style
delivery with the Postfix built-in local or virtual delivery agents;
b) mail delivery with non-Postfix local or virtual delivery agents;
c) mailbox-style delivery with the Postfix built-in virtual delivery
agent when virtual mailbox parent directories have no "group" or
other write permissions.
The following configurations are known to be affected on Linux
kernel >= 2.0, Solaris >= 2.0, OpenSolaris 11-2008.5, IRIX 6.5, and
other systems where users can create hardlinks to symlinks: a)
mailbox-style delivery with the Postfix built-in local delivery
Tony Finch <dot@dotat.at> wrote:
> According to POSIX, if you open the directory with O_SEARCH then openat()
> does not re-check search (+x) permissions.
My 2.6.26 kernel (or Debian lenny) does not seem to know about O_SEARCH.
But anyway... even if openat() does not re-check permissions, it should
surely fail when in fact it does not have permissions? Surely, directory
contents are not cached? Or, do you have an example (of a running OS)
where openat() succeeds without permissions?
It works on Debian 2.6.26 out of the box. It is not an obscure patched
kernel case I am afraid.
If you redir an FD to a file using thus redir-ed FD in /proc allows you
to bypass directory permissions for where the file is located.
Thankfully, file permissions still apply so you need an app which has
silly file perms in a bolted down directory for this.
Symlinking the same file to a link on a normal ext3 or nfs filesystem as
a sanity check shows correct permission behaviour. If you try to write
to that symlink you get permission denied so the permissions on the fs
Please specify Notes client version.
--Wednesday, August 22, 2007, 2:25:28 PM, you wrote to bugtraq@securityfocus.com:
kvgc> Local Privilege Escalation Through Default ntmulti.exe File Permissions
kvgc> Unprivileged users can execute arbitrary programs that run
kvgc> with the privileges of the LocalSystem account by replacing the
kvgc> Multi-user Cleanup Service executable with arbitrary executables.
kvgc> This vulnerability exists because the default file permissions
> It works on Debian 2.6.26 out of the box. It is not an obscure patched
> kernel case I am afraid.
>
> If you redir an FD to a file using thus redir-ed FD in /proc allows you
> to bypass directory permissions for where the file is located.
> Thankfully, file permissions still apply so you need an app which has
> silly file perms in a bolted down directory for this.
>
> Symlinking the same file to a link on a normal ext3 or nfs filesystem as
> a sanity check shows correct permission behaviour. If you try to write
> to that symlink you get permission denied so the permissions on the fs
> 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
Yes, you are right, open file descriptor acts as a kind of hardlink
Especially important: the last sentence!
Changing the access modes of a file descriptor is probably difficult
to implement. It may be feasible for file in the filesystem which
has an inode with access permissions which could be checked.
Doing it for a socket might be a bad idea -- and usually impossible,
one cannot undo the shutdown(SHUT_WR) of a socket...
>
Local Privilege Escalation Through Default ntmulti.exe File Permissions
Unprivileged users can execute arbitrary programs that run with the privileges of the LocalSystem account by replacing the Multi-user Cleanup Service executable with arbitrary executables. This vulnerability exists because the default file permissions assigned during installation to ntmulti.exe (the executable for the Multi-user Cleanup Service) allow unprivileged, interactive
users to replace ntmulti.exe with any file.
Because the Multi-user Cleanup Service is a Windows service running with LocalSystem privileges, unprivileged users can easily elevate their privileges.
1. 32Bit Version of Panda Security for Desktops/File Servers
+-----------------------------------------------------------
During installation of Panda Security for Desktops/File Servers the
permissions for installation folder
%ProgramFiles%\Panda Software\AVTC\
by default are set to Everyone:Full Control. Few services
(e.g. PAVSRV51.EXE) are started from this folder. Services are started
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
Next Page>>
|
