On Wed, Oct 28, 2009 at 10:30:37PM +0100, Pavel Machek wrote:
On Tue 2009-10-27 11:49:32, CaT wrote:
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
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
ZDI-09-074: Multiple Vendor Hummingbird STR Service Stack Overflow Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-09-074
October 28, 2009
-- Affected Vendors:
EMC
OpenText
-- Affected Products:
EMC Documentum eRoom
OpenText Hummingbird
OpenText Search Server
Hi!
Not that I would have expected anything different considering who posted
it in the first place.
Thus Debian kernel team should be blamed for that misbehaviour. Don't
worry,
hardlinks behave just the same way, as you describe. Use authentic Linux
kernels, if you dislike
On Tue 2009-10-27 11:49:32, CaT wrote:
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
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
||
Hi!
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-1922-1 secur...@debian.org
http://www.debian.org/security/ Moritz Muehlenhoff
October 28, 2009
##
Wowd search client multiple variable xss
Vendor URL: http://www.wowd.com/
Advisore:http://lostmon.blogspot.com/2009/10/
wowd-search-client-multiple-variable.html
Vendor notify:yes exploit available:yes
##
On Tue, Oct 27, 2009 at 03:34:04PM -0500, Derek Martin wrote:
$ 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 group13 2009-10-27 16:22 bar
$ chmod 000 .
On Tue 2009-10-27 21:19:19, Marco Verschuur wrote:
My buy.. :-( I persumed a re-use of the read-only FD, but that's not
the case.
I replayed it on a test-box and did some strace meanwhile and also
took a look
at the sourcecode of kernel/fs/proc.
It seems that the /proc filedescriptor is
Hijacking Opera's Native Page using malicious RSS payloads
-
For complete post (with images), please visit -
http://securethoughts.com/2009/10/hijacking-operas-native-page-using-malicio
us-rss-payloads/
Well,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
___
Mandriva Linux Security Advisory MDVSA-2009:290
http://www.mandriva.com/security/
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
p...@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
Pavel Machek wrote:
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
2WIRE REMOTE DENIAL OF SERVICE
Device: 2wire Gateway Router/Modem
Vulnerable Software: = 5.29.52
Vulnerable Models: 1700HG
1701HG
1800HW
2071
On Thu 2009-10-29 18:24:01, Dan Yefimov wrote:
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
18 matches
Mail list logo