full-disclosure - Re: vsFTPd remote code execution

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMnK33XZ3c5Dj+aUTcGQ7jmet2fvThW+Ss2vNUepnaOVBroDcA@mail.gmail.com>
Date: Tue, 13 Dec 2011 23:21:20 -0800
From: Chris Evans <scarybeasts@...il.com>
To: "HI-TECH ." <isowarez.isowarez.isowarez@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: vsFTPd remote code execution

On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH .
<isowarez.isowarez.isowarez@...glemail.com> wrote:
> Yes you are somewhat right, as this is the old discussion about if
> code execution inside an ftpd
> is a vulnerability itself or only local code execution. I have the
> opinion that an ftpd which does not allow to run code
> should restrict the user so, and if there is a way to execute code it
> it is a vulnerability.
> Take the example of a vsftpd configured for anonymous ftp and write
> access in /var/ftp.

IIRC, vsftpd can refuse to start an anonymous session for the
misconfiguration where the root directory is writeable (to avoid
problems in the libc like this). I'll make sure it still works and
maybe check other paths such as /etc

For local users, there's a configuration setting: "chroot_local_user".
The compiled-in default is false, and the man page cautions:
---
.BR Warning:
This option has security implications, especially if the users have upload
permission, or shell access. Only enable if you know what you are doing.
---

I'm not uptodate with whether Linux distributions have turned this on
by default or not.

vsftpd does have the concept of "virtual users". I'm not sure if it's
widely used but it seems that this type of user login would present
the biggest headache.

Amusingly, vsftpd already attempts to desist glibc from loading any
timezone files from inside the chroot() (see env_init) by warming up
the subsystem and even explicitly setting TZ in the environment. glibc
displeases me. Perhaps it's a gmtime() vs. localtime() issue -- I'm
curious to know if glibc still crashes if the setting
"use_localtime=YES" is used?

I don't mind adding workarounds or avoidances for libc bugs (for
example, functions like regcomp, fnmatch have long been avoided). If
you had any clever ideas, I'm happy to put them in, otherwise it's a
case of waiting for the glibc updates.

Cheers
Chris

> The attacker might
> execute code using the vulnerability without authentication
> credentials, or for example an attacker only has
> access to a user account configured for ftp.
> Basically you are right, vsftpd uses privsep so its a not so risky
> vulnerability.
>
> /Kingcope
>
> Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg <dan.j.rosenberg@...il.com>:
>>> Anyone with an up2date linux local root which only makes use of syscalls? :>
>>>
>>
>> This is all fun stuff, and definitely worth looking into further, but
>> if you've got a local kernel exploit that you can trigger from inside
>> vsftpd, you don't need this (potential) vulnerability in vsftpd - you
>> already win.
>>
>> -Dan
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/