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

[" Ángel González " <[e-mail]>]

Mark P. Peterson wrote:
> Hi Ángel,
>
> RMDA
> -------
>> 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.
>
> THMB
> -------
>>  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
larger.


> 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:
http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability
http://blogs.techrepublic.com.com/itdojo/?p=892
http://www.sophos.com/pressoffice/news/articles/2004/09/va_critical16sep04.html
http://www.kb.cert.org/vuls/id/680620
http://www.kb.cert.org/vuls/id/238678
http://www.libpng.org/pub/png/libpng.html
http://secunia.com/advisories/27213/
http://hypersecurity.blogspot.com/2010/03/cve-2010-0188-adobe-reader-tiff.html

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
great
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