Bug#304712: avaMail allows directory traversal in attachments (CAN-2005-1105)

2007-04-25 Thread Javier Serrano Polo
El dc 25 de 04 del 2007 a les 07:12 +0200, en/na Florian Weimer va
escriure:
 It's from the GNU implementation against which this bug report was
 filed.

I still don't know the origin. It may be from JavaMail 1.3.2
implementation.

http://cvs.savannah.gnu.org/viewcvs/mail/source/javax/mail/internet/MimeBodyPart.java?root=classpathxr1=1.1r2=1.2
This was the initial documentation and the current one is very similar.

gnumail has never had that text in its implementation.



___
pkg-java-maintainers mailing list
pkg-java-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers


Bug#304712: avaMail allows directory traversal in attachments (CAN-2005-1105)

2007-04-25 Thread Javier Serrano Polo
El dc 25 de 04 del 2007 a les 11:44 +0200, en/na Javier Serrano Polo va
escriure:
 I still don't know the origin. It may be from JavaMail 1.3.2
 implementation.

Looking at section 7. VULNERABLE SOURCE CODE, it looks like the
original submitter didn't check any documentation.



___
pkg-java-maintainers mailing list
pkg-java-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers


Bug#304712: avaMail allows directory traversal in attachments (CAN-2005-1105)

2007-04-24 Thread Florian Weimer
* Javier Serrano Polo:

 The JavaMail spec is clear enough about what should (must) do the
 implementation. As Chris already said, it returns the actual message
 content. Security isn't handled in this step. Any implementation
 altering this value doesn't follow the spec. Any application relying on
 extra security checks would be based on a implementation (defeating the
 portability goal), not on the API.

I guess the documentation shoud be clarified:

| Get the filename associated with this part, if possible. Useful if
| this part represents an attachment that was loaded from a file. The
| filename will usually be a simple name, not including directory
| components.

Something like ... but such components may be present.  Applications
must take care to remove them before creating files with the indicated
name., perhaps.


___
pkg-java-maintainers mailing list
pkg-java-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers


Bug#304712: avaMail allows directory traversal in attachments (CAN-2005-1105)

2007-04-24 Thread Javier Serrano Polo
El dt 24 de 04 del 2007 a les 19:17 +0200, en/na Florian Weimer va
escriure:
 I guess the documentation shoud be clarified:

I don't know where that text came from (it's in a previous link, I
know). From:

http://java.sun.com/j2ee/1.4/docs/api/javax/mail/internet/MimeBodyPart.html#getFileName()

Get the filename associated with this body part. 

Returns the value of the filename parameter from the
Content-Disposition header field of this body part. If its not
available, returns the value of the name parameter from the
Content-Type header field of this body part. Returns null if
both are absent.

Pretty clear, isn't it?



___
pkg-java-maintainers mailing list
pkg-java-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers


Bug#304712: avaMail allows directory traversal in attachments (CAN-2005-1105)

2007-04-24 Thread Florian Weimer
* Javier Serrano Polo:

 El dt 24 de 04 del 2007 a les 19:17 +0200, en/na Florian Weimer va
 escriure:
 I guess the documentation shoud be clarified:

 I don't know where that text came from (it's in a previous link, I
 know). From:

It's from the GNU implementation against which this bug report was
filed.

 http://java.sun.com/j2ee/1.4/docs/api/javax/mail/internet/MimeBodyPart.html#getFileName()

 Get the filename associated with this body part. 
 
 Returns the value of the filename parameter from the
 Content-Disposition header field of this body part. If its not
 available, returns the value of the name parameter from the
 Content-Type header field of this body part. Returns null if
 both are absent.

 Pretty clear, isn't it?

As far as a specification goes, yes, but it could be more helpful to
those who try to use this API safely.


___
pkg-java-maintainers mailing list
pkg-java-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers