Closed Bug 938988 Opened 11 years ago Closed 11 years ago

SecReview: FxOS POP3 support

Categories

(mozilla.org :: Security Assurance: Review Request, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pauljt, Assigned: freddy)

References

Details

(Whiteboard: u= c= p=2 s=ready triage-ignore)

Attachments

(1 file)

Security review to look at pop support landing in 1.3  (916080, 916083, 916088, 916090)
Assignee: nobody → fbraun
Assignee: fbraun → nobody
Whiteboard: u= c= p=1 s=ready → u= c= p=1 s=ready triage-ignore
Whiteboard: u= c= p=1 s=ready triage-ignore → u= c= p=2 s=ready triage-ignore
Assignee: nobody → fbraun
Hey Andrew,
I need some additional feedback (maybe a quick chat?) about the HTML fragments in pop3.js. The idea is to make sure that POP3 itself isn't touching the markup but the consumer of it is, so we can leverage existing defense mechanisms.
Flags: needinfo?(bugmail)
Marcus implemented the POP3 implementation so should be the point-man for this.  I reviewed and can comment too, but the security review is part of the fun of landing a giant patch! ;)

Pinging in #gelam for either of us when it's your daytime again is probably the best way since we both lurk there too and can see the discussion in scrollback.  (From IRC I understand it's now late in the Berlin area.)

The short answer is that we don't pass "showAttachmentLinks" to the MailParser, so the _joinHTMLAttachment method should never be called.

Code-reading-wise, it does look like _joinHTMLNodes is probably getting called, but that its byproducts are ignored.  Specifically, it mutates the contents of mailParserInstance.mailData.html[N].content, but mailData.html is populated by pushing an object whose content is just a reference to the mime node's 'content'.  So manipulating mailData.html[N].content does not affect mimeNode.content.  We just consume mimeNode.content.

(Also, one could argue that even if we consumed mailData.html[N].content that we still sanitize that, so it doesn't matter.)

Of course, unit tests speak louder than anything, so I would propose that we add a test case to test_mime.js in GELAM that is a multipart/mixed consisting of two text/html parts and that we ensure that we don't see any random joining HTML inserted.  We might even go further and have a structure like the following because MailParser even has a concept of levels for processing like this (which is really impressively thorough):
- multipart/mixed
  - text/html
  - multipart/mixed
    - text/html
    - text/html
Flags: needinfo?(bugmail) → needinfo?(mcav)
Attached file gelam.html (deleted) β€”
GELAM test_mime unit test to ensure that when we parse a MIME message with adjacent HTML nodes (nested in multipart/mixed for good measure), we don't include extra stuff in the content.
Flags: needinfo?(mcav)
Attachment #8345575 - Flags: review?(bugmail)
Yeah, Freddy, I'm happy to be the point man and try to answer any questions you have. Andrew's a busy man! I added a unit test per Andrew's comment, but if you have more questions on this or other stuff, feel free to ping me either here, or #gelam, or wherever.
Comment on attachment 8345575 [details]
gelam.html

You sir, are dangerously on the ball.

Great test, thanks for the ridiculously fast turnaround.
Attachment #8345575 - Flags: review?(bugmail) → review+
Thanks for following up so quickly. Adding a unit test was a great idea. 
Let's set this bug to Resolved/Fixed once the test has landed.
Landed.

https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/567dcc0942ce421d72fb99cb3439304ba88089a7
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: