194449 - POP Security Review Action Items

Status: NEW

(MailNews Core :: Networking: POP, defect)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Make sure return receipt requests are not sent along with forwarded messages

Can POP be configured for "highest available security" (SSL when possible)?

We should extend the internal/external URL enforcement to all Mozilla-internal
protocols (mailbox, newsmessage, mailmessage, etc.) and possibly pop.

pop and pop3 should both be "denyProtocol" in CheckLoadURI

Make it so we never send out pop, imap, mailbox, or file URLs as links or
attachment names, including drag-and-dropped attachments. More generally, we
shouldn't be revealing any unnecessary information in mail headers.

Should we block attachments, or warn the user, on a mailto:?

What happens when you use various mail schemes as a form action URL?

Are we checking for .. in mailbox URL paths, and in other paths where necessary?

We should filter control chars (returns) out of username, password, folder
names, and other opaque strings passed in the POP protocol and other protocols.

Look at what can be done with a malicious pop/imap/news server. Will reporting
too many messages cause a crash? Any buffer overruns? We should hack a pop
server to deliver unexpected content/large values.

We should have a "sensitive buffer" class for storing passwords and other
sensitive data in memory, that zeros itself out before freeing, and that won't
be swapped to disk. There's probably an existing implementation of this - we
should find it.

Look at DOM issues for when JS is enabled in the message pane. What
manipulations of the message DOM will cause problems?

Comment 1

[Daniel Veditz [:dveditz]]

bienvenu: is there anything useful left in this bug or can we resolve it and/or unhide it as a security bug?

Comment 2

[David :Bienvenu]

(In reply to Daniel Veditz [:dveditz] from comment #1)
> bienvenu: is there anything useful left in this bug or can we resolve it
> and/or unhide it as a security bug?

I think we can unhide it. Pop3 urls have URI_DANGEROUS_TO_LOAD set. We default to SSL/TLS if possible. JS is not longer enabled in the message pane. There may be some useful things to investigate in the bug, but hiding it isn't going to help them get investigated.

Comment 3

[Wayne Mery (:wsmwk)]

perhaps good timing to review these items, given the pop update ?

Comment 4

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #3)

perhaps good timing to review these items, given the pop update ?

Redirecting to Ping who implemented POP in javascript in bug 1707548.

Comment 5

[Ping Chen [:rnons] (away)]

Regarding this bug, I don't think pop3-js did anything different from pop3-cpp. The title says pop, but most of comment 0 applies to all our protocols. I think these two points are still valid

Look at what can be done with a malicious pop/imap/news server. Will reporting
too many messages cause a crash? Any buffer overruns? We should hack a pop
server to deliver unexpected content/large values.

We should have a "sensitive buffer" class for storing passwords and other
sensitive data in memory, that zeros itself out before freeing, and that won't
be swapped to disk. There's probably an existing implementation of this - we
should find it.