headers
Nelson Elhage | 1 Mar 2011 01:13

Re: CVE request: kernel: OOM-killer via argv expansion

On Mon, Feb 28, 2011 at 03:28:47PM -0800, Kees Cook wrote:
> On Mon, Feb 28, 2011 at 01:02:02PM -0800, Kees Cook wrote:
> > On Mon, Feb 28, 2011 at 12:32:55PM -0800, Kees Cook wrote:
> > > I think the flaw[1] with argv-expansion triggering the OOM-killer
> > > incorrectly needs its own CVE.
> > > 
> > > While the stack guard page and the fixes[2] for CVE-2010-3858 certainly
> > > improved things, argv expansion can still be tricked into OOM-killing the
> > > entire system. Solutions were discussed on the original thread, but
> > > were not finished. Recently a set of patches[3] has been re-proposed to fix
> > > this issue. Regardless, it should probably get its own CVE assigned.
> > > 
> > > Thanks,
> > > 
> > > -Kees
> > > 
> > > [1] https://lkml.org/lkml/2010/8/27/429
> > > [2] http://git.kernel.org/linus/1b528181b2ffa14721fb28ad1bd539fe1732c583
> > > [3] https://lkml.org/lkml/2011/2/25/227
> > 
> > Sorry, Nelson Elhage pointed out to me that I missed the fix for this
> > issue. The issue was been fixed with:
> > http://git.kernel.org/linus/3c77f845722158206a7209c45ccddc264d19319c
> > 
> > This was already assigned as CVE-2010-4243
> > 
> > Sorry for the noise, and thanks!
> 
> Wait, I will continue to make more noise. The upstream commit
> 3c77f845722158206a7209c45ccddc264d19319c does not handle the compat case,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eugene Teo | 1 Mar 2011 01:30
Picon
Favicon

Re: CVE request: kernel: OOM-killer via argv expansion

On 03/01/2011 08:13 AM, Nelson Elhage wrote:
> On Mon, Feb 28, 2011 at 03:28:47PM -0800, Kees Cook wrote:
>> On Mon, Feb 28, 2011 at 01:02:02PM -0800, Kees Cook wrote:
>>> On Mon, Feb 28, 2011 at 12:32:55PM -0800, Kees Cook wrote:
>>>> I think the flaw[1] with argv-expansion triggering the OOM-killer
>>>> incorrectly needs its own CVE.
>>>>
>>>> While the stack guard page and the fixes[2] for CVE-2010-3858 certainly
>>>> improved things, argv expansion can still be tricked into OOM-killing the
>>>> entire system. Solutions were discussed on the original thread, but
>>>> were not finished. Recently a set of patches[3] has been re-proposed to fix
>>>> this issue. Regardless, it should probably get its own CVE assigned.
>>>>
>>>> Thanks,
>>>>
>>>> -Kees
>>>>
>>>> [1] https://lkml.org/lkml/2010/8/27/429
>>>> [2] http://git.kernel.org/linus/1b528181b2ffa14721fb28ad1bd539fe1732c583
>>>> [3] https://lkml.org/lkml/2011/2/25/227
>>>
>>> Sorry, Nelson Elhage pointed out to me that I missed the fix for this
>>> issue. The issue was been fixed with:
>>> http://git.kernel.org/linus/3c77f845722158206a7209c45ccddc264d19319c
>>>
>>> This was already assigned as CVE-2010-4243
>>>
>>> Sorry for the noise, and thanks!
>>
>> Wait, I will continue to make more noise. The upstream commit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eugene Teo | 1 Mar 2011 10:07
Picon
Favicon

Re: CVE request - kernel: xfs infoleak

On 02/16/2011 04:41 PM, Eugene Teo wrote:
>  From Dan R0s3nbug5, "The FSGEOMETRY_V1 ioctl (and its compat
> equivalent) calls out to xfs_fs_geometry() with a version number of 3.
> This code path does not fill in the logsunit member of the passed
> xfs_fsop_geom_t, leading to the leaking of four bytes of uninitialized
> stack data to potentially unprivileged callers. Since all other members
> are filled in all code paths and there are no padding bytes in this
> structure, it's safe to avoid an expensive memset() in favor of just
> clearing this one field."
>
> https://patchwork.kernel.org/patch/555461/
> https://bugzilla.redhat.com/show_bug.cgi?id=677260

There's an issue with the patch, here's the fix to the fix:
http://www.spinics.net/lists/xfs/msg03801.html

Eugene
--

-- 
Eugene Teo / Red Hat Security Response Team
Permalink | Reply | 0 comments |
headers
Pierre Joye | 1 Mar 2011 10:11
Picon
Gravatar

Re: CVE Request: PEAR Installer 1.9.1 <= - Symlink Attack

hi,

2011/2/28 Dan Rosenberg <dan.j.rosenberg@...>:
> I'm not familiar with this code or any of the context surrounding this
> fix, but it appears to be an incomplete fix.  Checking for existence
> of a symlink and then opening the resource leaves open a window during
> which a legitimate file can be replaced with a symlink.

Not sure it is fixable, or maybe using a lock on the symbolic link
while fetching its target (to be tested to be sure that such locks
cannot be overridden from shell).

> Also, I don't see a reason why a hard link couldn't be used for exploitation
> instead.

Hard link are not detectable (lstat), they are treated like normal files.

Cheers,
--

-- 
Pierre

 <at> pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Permalink | Reply | 7 comments |
headers
Helgi Þormar Þorbjörnsson | 1 Mar 2011 11:24
Picon
Gravatar

Re: CVE Request: PEAR Installer 1.9.1 <= - Symlink Attack

Hi, 
On 1 Mar 2011, at 09:11, Pierre Joye wrote:

> hi,
> 
> 2011/2/28 Dan Rosenberg <dan.j.rosenberg@...>:
>> I'm not familiar with this code or any of the context surrounding this
>> fix, but it appears to be an incomplete fix.  Checking for existence
>> of a symlink and then opening the resource leaves open a window during
>> which a legitimate file can be replaced with a symlink.
> 
> Not sure it is fixable, or maybe using a lock on the symbolic link
> while fetching its target (to be tested to be sure that such locks
> cannot be overridden from shell).

I assume you are referring to the parts for REST.php in the patch in question?
At a second look, that part could do with improvements; I wrote up a function which takes TOCTOU into consideration.
I'll have that patch done by the end of the day.

For other situations I am using tempnam() (via the System class) as those files are only temporary and were
being extracted from compressed archives; The predictability of their end destination where the centre
part of the reported security problem.

- Helgi
Permalink | Reply | 1 comment |
headers
henri | 1 Mar 2011 11:57
Picon
Gravatar

CVE request: Atlassian JIRA Parameter-Based Redirection Vulnerability

Can I get CVE-identifier for this issue:

http://confluence.atlassian.com/display/JIRA/JIRA+Security+Advisory+2011-02-21
http://secunia.com/advisories/43384

Best regards,
Henri Salo
Permalink | Reply | 1 comment |
headers
Dan Rosenberg | 1 Mar 2011 13:19
Picon

Re: CVE Request: PEAR Installer 1.9.1 <= - Symlink Attack

> Not sure it is fixable, or maybe using a lock on the symbolic link
> while fetching its target (to be tested to be sure that such locks
> cannot be overridden from shell).
>

The easiest way is to just open the target with the O_NOFOLLOW flag to
avoid following symlinks and abort on failure.  If you need to support
systems that don't have this flag, then perhaps you could consider
using an application-specific temporary directory instead of operating
in the world-writable /tmp.

>> Also, I don't see a reason why a hard link couldn't be used for exploitation
>> instead.
>
> Hard link are not detectable (lstat), they are treated like normal files.
>

Sure they are - just open the file, fstat() it, and check the st_nlink
field.  If it's more than one, you know there's hard linking going on.
 Sometimes this kind of check introduces a race condition of its own
where the file can be removed by the attacker after a file descriptor
is obtained but before the fstat(), but in this case since an attacker
would be creating a hard link to a victim's file, he wouldn't be able
to remove it since it's in a sticky-bit /tmp directory.

-Dan
Permalink | Reply | 4 comments |
headers
Pierre Joye | 1 Mar 2011 13:21
Picon
Gravatar

Re: CVE Request: PEAR Installer 1.9.1 <= - Symlink Attack

On Tue, Mar 1, 2011 at 1:19 PM, Dan Rosenberg
<dan.j.rosenberg@...> wrote:

> The easiest way is to just open the target with the O_NOFOLLOW flag to
> avoid following symlinks and abort on failure.  If you need to support
> systems that don't have this flag, then perhaps you could consider
> using an application-specific temporary directory instead of operating
> in the world-writable /tmp.

In php, hard to do. But that's something we should keep in mind, maybe
we can expose this flag somehow.

>>> Also, I don't see a reason why a hard link couldn't be used for exploitation
>>> instead.
>>
>> Hard link are not detectable (lstat), they are treated like normal files.
>>
>
> Sure they are - just open the file, fstat() it,

+from PHP script.

--

-- 
Pierre

 <at> pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Permalink | Reply | 0 comments |
headers
Helgi Þormar Þorbjörnsson | 1 Mar 2011 13:39
Picon
Gravatar

Re: CVE Request: PEAR Installer 1.9.1 <= - Symlink Attack


On 1 Mar 2011, at 12:19, Dan Rosenberg wrote:

>> Not sure it is fixable, or maybe using a lock on the symbolic link
>> while fetching its target (to be tested to be sure that such locks
>> cannot be overridden from shell).
>> 
> 
> The easiest way is to just open the target with the O_NOFOLLOW flag to
> avoid following symlinks and abort on failure.  If you need to support
> systems that don't have this flag, then perhaps you could consider
> using an application-specific temporary directory instead of operating
> in the world-writable /tmp.

The PEAR installer does use /tmp (and whatever the Windows equivalent is) by default unless the user opts
into a local installation or does indeed change the configuration to use other temp/download/cache
directories so users can guard themselves with a good setup.

A flag like that would be handy but doesn't exist (yet) in PHP. 

I moved over to using the O_CREAT|O_EXCL equivalent in PHP when creating new files and lstat + fopen + fstat
and comparing mode/ino/dev before writing to an existing file for the cache. I could add an nlink check to
that as well.
The current version I've been playing around with is located at https://gist.github.com/848371 - It is
missing the nlink part but it should be able to deal with TOCTOU problems. That code snippet hasn't been
committed as I consider it work-in-progress still.

Any comments / suggestions are welcome, I did write that one quite late last night :-)

- Helgi
(Continue reading)

Permalink | Reply | 2 comments |
headers
Petr Matousek | 1 Mar 2011 16:46
Picon
Favicon

Re: CVE request: kernel: two bluetooth and one ebtables infoleaks/DoSes

> "struct sco_conninfo has one padding byte in the end. Local variable
> cinfo of type sco_conninfo is copied to userspace with this
> uninizialized one byte, leading to old stack contents leak."
> 
> https://lkml.org/lkml/2011/2/14/49

Please use CVE-2011-1078.

> "Struct ca is copied from userspace. It is not checked whether the
> "device" field is NULL terminated. This potentially leads to BUG()
> inside of alloc_netdev_mqs() and/or information leak by creating a
> device with a name made of contents of kernel stack."
> 
> https://lkml.org/lkml/2011/2/14/50

Please use CVE-2011-1079.

> "Struct tmp is copied from userspace. It is not checked whether the
> "name" field is NULL terminated. This may lead to buffer overflow and
> passing contents of kernel stack as a module name to
> try_then_request_module() and, consequently, to modprobe commandline.
> It would be seen by all userspace processes."
> 
> https://lkml.org/lkml/2011/2/14/51

Please use CVE-2011-1080.

Thanks you,
--
Petr Matousek / Red Hat Security Response Team
(Continue reading)

Permalink | Reply | 0 comments |

Gmane