-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aruba Networks Security Advisory
Title: Malformed 802.11 Association Request frame causes Denial of
Service condition on an Access Point.
Aruba Advisory ID: AID-102609
Revision: 1.0
For Public Release on 10/26/2009
+
On 26.10.2009 23:05, Isara Beaumont wrote:
Dan Yefimov said:
I do not think mounting /proc should change access control semantics.
It didn't in fact change anything. If the guest created hardlink to that file in
a unrestricted location, what would you say? Procfs is in that respect just
anoth
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 an
Why not?!?
File permissions allow everybody write access to the file.
The path via /proc to the file has been created when the initial path
via /tmp was wide open.
Closing the initial path via /tmp has no effect on the /proc path
And due to the actual file permissions the read-only fd can eas
Hi!
> >pa...@toy:/tmp$ uname -a
> >Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel
> >GNU/Linux
> >pa...@toy:/tmp mkdir my_priv; cd my_priv
>
> Attacker opens my_priv and waits.
...
> >pa...@toy:/tmp/my_priv$ cat unwritable_file
> >this file should never be writable
>
>
Marco Verschuur wrote:
> And due to the actual file permissions the read-only fd can easily
> changed to read-write.
How would you do that? Cannot use fcntl() as that would not let you.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathemati
On Mon, 26 Oct 2009, Matthew Dempsky wrote:
> On Mon, Oct 26, 2009 at 9:01 AM, Tony Finch wrote:
> >
> > Attacker uses openat() to open and modify the "private" file.
>
> At least with Linux 2.6.18, you still need +x permission on the
> directory to access its contents using openat(2).
According
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
||
On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
> and testing them. Remember the scenario from the original mail and try
> finding a window, during which creating a hardlink would still work thus
> evading directory permissions check.
The main thing this does is allow a hardlink-lik
#
Application: Rising Antivirus 2009
Platforms: Windows XP Professional SP2
Exploitation: Privilege Escalation
Date: 2009-10-26
Author: Francis Provencher (Protek Research Lab's)
Vulnerability like in topic (connected with vulns in xpdf). More details
available here:
==
Last few weeks I was talking(mailing) with Derek (xpdf developer
btw. really nice guy) about some vulnerabilities in his product. 14th of
October he published path for bugs (not only my vulnerab
#
Application: Rising Firewall 2009
Platforms: Windows XP Professional SP2
Exploitation: Privilege Escalation
Date: 2009-10-26
Author: Francis Provencher (Protek Research Lab's)
ShineShadow Security Report 28102009-13
TITLE
Rising Multiple Products Local Privilege Escalation Vulnerability
BACKGROUND
RISING has introduced a variety of operating system based antivirus software,
firewall software and enterprise antivirus wall, firewall, network security
warning system
Tony Finch wrote:
> Attacker opens [directory] and waits. ...
> Attacker uses openat() to open and modify the "private" file.
Surely if the permissions do not allow lookup then openat() will fail.
[The attacker opened directory when it was searcheable; then permissions
were closed; then attacker
14 matches
Mail list logo
