Re: ZA Security Hole

From: David Wilson (David.Wilson_at_isode.com)
Date: 04/20/04

  • Next message: CoKi: "Format String in Cherokee"
    To: Damjan Kreft <damjan.kreft@siol.net>
    Date: Tue, 20 Apr 2004 08:52:07 +0100
    
    

    On Wed, 2004-04-14 at 21:44, Damjan Kreft wrote:
    > Hello!
    >
    > I think, I discover some kind of security hole in ZoneAlaram - any version.
    > The problem is hidding in E-mail Protection. Because I'm form Slovenia (not
    > Slovakia), our alphabet does have some letters with roof (c - , s - , z -
    > ). And when the name of e-mail attachment contain any of these three
    > letters, it don't go to the qurarantine (if the attachment do have right
    > extension of course). I think that can be security threat. From this reason
    > I write to you. If this is mistake, I'm sorry to steal your time with this
    > e-mail. And sorry for my bad english :)

    I do not know the ZoneAlarm product, but I presume you are attempt to
    use a feature which blocks Email attachments which have an associated
    filename which ends in .exe (or whatever).

    I think there might be two possible explanations:

    1) There is a bug in ZoneAlarm. This is suggested by the correspondent
    who reported a problem with a filename containing '()'. This does not
    require any special encoding (although a stupid UA might use the method
    I outline below when it is not needed).

    2) ZoneAlarm is not bug-for-bug compatible with certain mail user agents
    which are in specific violation of the Internet standards.

    The associated filename appears in the (non-standard) name parameter to
    the Content-type, or the standard filename parameter to the
    Content-disposition field. In common with all MIME headers, it cannot
    contain characters other than US-ASCII. So, how do you get a filename
    with non-ASCII? There is a standard for this: RFC 2231 (published in
    November 1997, so there has been a long time for software writers to
    adopt this).

    However, some software I have seen ignores this standard. Instead, these
    use MIME 'encoded words' (RFC 2047). These are intended for use in
    standard RFC 2822 headers to include non-ASCII, but can only be used in
    specific locations, such as the subject field, and the "name" part of
    addresses. The RFC contains this specific prohibition:

       + An 'encoded-word' MUST NOT be used in parameter of a MIME
         Content-Type or Content-Disposition field, or in any structured
         field body except within a 'comment' or 'phrase'.

    The value part of a parameter is not syntactically a 'phrase', so this
    prohibition is unambiguous.

    So, software which conforms to standards should not be expecting an
    encoded-word within a MIME parameter, so it will not attempt to interpret it.
    However, non-conforming software WILL decode the word, find the trailing .exe
    and then assume that the attachment is executable.

    This is a real dilemma for any software which has the intention of preventing
    unsafe content from reaching the user. It is only necessary because the main
    software the user is using is itself unsafe and insecure. But the protecting
    software has to know how the unsafe software is going to treat any possible
    input. If the unsafe software is not standards conforming, but more lax, then
    that is a real problem for the writers of the protecting software. They have
    to know the whole behaviour of the unsafe software.

    Another example of this is the lax treatment of text/plain. The MIME type and
    sub-type should be the first items used to determine the treatment of a MIME
    body. However, some systems ignore this, and if it contains HTML, for instance,
    render the HTML. Even worse, some systems could treat the text/plain as executable.

    So, check the 'raw' message and look at how the filename appears in the MIME
    headers for the attachment. If it is an encoded-word, the problem is
    standards-violating software, but ZoneAlarm does not allow for this.

    -- 
    David Wilson <David.Wilson@isode.com>
    Isode Limited
    

  • Next message: CoKi: "Format String in Cherokee"

    Relevant Pages

    • Re: 2nd RfD: Directories
      ... ordinary programmer (not versed in all the subtleties of the standard) ... such chance if we are on, say, VMS, and OPEN-FILE does not translate. ... the filename is not well-formed for the system ... ... the OS-native way, he may not be able to use the standard file words, ...
      (comp.lang.forth)
    • Re: relative-to-source file names (was: Small, understandable Forth)
      ... The #include analogy would be "filename" for source file relative and ... source file currently being interpreted, the file is relative to the ... The file reference pointed to by is converted to an absolute ... You can only add a new standard capability by adding one or more ...
      (comp.lang.forth)
    • RE: Automating Import process...
      ... Create a new standard module.... ... On Error GoTo R5561115Import_Err ... 'Open the OpenFile Dialog box to get the .csv filename ... "Steve Sanford" wrote: ...
      (microsoft.public.access.modulesdaovba)
    • Re: Getting path components
      ... path, filename, and extension? ... Standard C does not place any interpretation upon filenames ... There are valid Unix file names that look -exactly- the same ... that in MacOS that ':' was the directory seperator... ...
      (comp.lang.c)