Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions

" Ángel González " <> Wed, 24 November 2010 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 539E728C13A for <>; Wed, 24 Nov 2010 12:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EaJ71zm5MRnl for <>; Wed, 24 Nov 2010 12:35:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7A17E28C149 for <>; Wed, 24 Nov 2010 12:35:44 -0800 (PST)
Received: by wwa36 with SMTP id 36so135308wwa.13 for <>; Wed, 24 Nov 2010 12:36:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+f2qLN2C2USbUxMVnpK+qsR+S/rDF3eAYO9XcPci5H8=; b=bjb23/kS9xShY4PO8Tw/nBKi1Mmi0KFqrpkuCnNoGGEKyAhN83I90AhvzjuPmfnXge +oBsHAxtRAc80hja//O7cpTnYPNSUeN1uzqT2M6p3nmkIyI4EhO9OsL9B+zkpTWR22aU f3dmHh7B1KfZNDZaULJrXf8T5ck4TCN5EELVM=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FZwnGKp3MUgQY9pVo9sncoIM16+k8n2wVPQiUuRR9aE1/fdxCD4ReuyXw9j5b1U44u KqtPyL5THodzqLUd0/IzC2+uEv/Ci+W4NxCBmTx3FqYFLNhs5NAoNoWiy2V/xKkA/6Kz 2rem2W2CIwfye7KrtAcgcOOk4eugtXedk7jpg=
Received: by with SMTP id w19mr8438765wek.88.1290631003383; Wed, 24 Nov 2010 12:36:43 -0800 (PST)
Received: from [] ( []) by with ESMTPS id x59sm3676029weq.14.2010. (version=SSLv3 cipher=RC4-MD5); Wed, 24 Nov 2010 12:36:41 -0800 (PST)
Message-ID: <>
Date: Wed, 24 Nov 2010 21:36:58 +0100
From: Ángel González <>
User-Agent: Thunderbird
MIME-Version: 1.0
To: "Mark P. Peterson" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Nov 2010 20:35:46 -0000

Mark P. Peterson wrote:
> Hi Ángel,
> -------
>> If the folder being RMDAed is not deletable by the logged in user, the
> server MAY -based both on its configuration and user credentials-
> directly reject the command. On the other hand, if it deletes one file
> (and can not rollback the operation), it must continue the whole subtree.
> I will add this to the document.
> -------
>>  It should allow full MIME types, so an application/x-better-image-format could be used.
> I cannot find a reason to disagree, so I agree that following a standard for
> identifying the thumbnail type should be used.  I could use your help here
> clarifying my document.
>> I also prefer the OPTS syntax, since that would allow larger options and
> extensions, such as:...
> I prefer specifying the parameters in the command for two primary reasons.
> 1) By requiring a client to use OPTS to specify output type and resolution
> the client and server must exchange this information in a separate command.
> Commands require a handshake and consequently some latency between the
> server and client for the exchange.  Depending on many different factors this
> latency, even on a fast connection, can be noticeable.  If the client wants different
> sized images frequently, let's say for every thumbnail image, it would be
> even more noticeable.  The bandwidth required to specify 10 bytes or less as a
> parameter to the command is trivial by comparison even on the slowest
> connections.
Sure, but why would the client want differently sized images frequently?
I think the client would only need to state it once, perhaps with a
change on
window resize. The number of thumbnails on a typical case would be much

> 2) By requiring a client to use OPTS to identify the parameters, both the client
> and the server must maintain the parameters for this command, more-or-less
> as a state.  I'm a big fan of keeping things very simple.
There is a trade off here. Although it is tempting to not store anything
at the server
for this, I still consider that using OPTS is a better route.

> 3) End-user support is easier when parameters are specified with the command.
> When end-users or customers have problems they'll often provide a portion of a
> log to identify what is going on with the communication between the server and
> client.  Technicians analyzing the log may not have all of the required information
> regarding the THMB command.  With the parameters being issued with the
> command analysis is far simpler and accurate.
The server could repeat the options in the 150 response if it is deemed
needed for
user support.

>> There should be a note about the potential security issues of the THMB
> command. Vulnerabilities processing images are common.
> Could you give me some examples or how you would like to see this worded
> and where you would like to see this placed in the document?

Doing a bit of googling for image vulnerabilities:

Vulnerabilities in image processing are quite bad, because it is easy to
make a client
render an image.THMB adds image rendering to ftp servers, which have a
exposure to the public.
These vulnerabilities often allow arbitrary code execution, but even a
DoS would be
bad for a ftp server. Most importantly, an attacker must not be able to
get LocalSystem/root
access on a server by just uploading a malicious image. Not even if the
fault lies on
some OS-provided library used for the thumbnailing.

I suppose the appropiate section is the security one, with a note to it
from THMB.
I don't know if it should be introduced by noting how thumbnailing adds
a significant
amount of code and how image vulnerabilities appear from time to time.

The main piece could be similar to this:
> Server implementations should be prepared in advance to mitigate
> vulnerabilities in
> the libraries used for thumbnailing. Servers are encouraged to perform
> all thumbnailing
> operations in a low-privilege process isolated from the server one.

Best regards