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?
Product: Core → MailNews Core
7 years ago
QA Contact: esther → networking.pop
bienvenu: is there anything useful left in this bug or can we resolve it and/or unhide it as a security bug?
Assignee: naving → dbienvenu
Whiteboard: [sg:investigation] → [sg:audit]
(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.
You need to log in before you can comment on or make changes to this bug.