Bugzilla – Full Text Bug Listing
| Summary: | EE4J JavaMail APi CRLF Injection Attack | ||
|---|---|---|---|
| Product: | Community | Reporter: | Dhruv Gramopadhye <dgramopadhye> |
| Component: | Vulnerability Reports | Assignee: | Security vulnerabilitied reported against Eclipse projects <vulnerability.reports-inbox> |
| Status: | RESOLVED NOT_ECLIPSE | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | bill.shannon, dgramopadhye, learnsecurity, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Dhruv Gramopadhye
Project team: I've moved this bug to the "Vulnerability Reports" component and have marked it "committers only" to reduce the level of disclosure. Our vulnerability management process and related services is documented in the handbook: https://www.eclipse.org/projects/handbook/#vulnerability An application using SMTPMessage/MimeMessage can also open a TCP connection to the mail server directly and issue whatever commands it wants. These classes don't give the application any capabilities it doesn't already have. Why do you think this is a security vulnerability? I figured this question would be asked. I consider this a security vulnerability because a lot of web applications written in Java use this API to send mail. This usually means that user-provided input is passed directly to JavaMail - developers expect JavaMail to abstract mail sending, and handle security involved with sending mail. I understand that a program that uses JavaMail as a dependency can just open a TCP connection by itself, and the fact that it uses JavaMail means that it can already send arbitrary emails. That said, these classes do provide remote attackers with the ability to take over the connection when used in the context of a web application. Since developers expect JavaMail to abstract sending mail, I think security should be JavaMail's responsibility as well. JavaMail handles security, but not input validation, since it's not an application that interfaces directly with users. If you find applications that don't validate input, you should file bugs against those applications. Recent versions of JavaMail make it much less likely that unvalidated input will allow an attacker to subvert the communication with the server. That doesn't make it impossible for a poorly written or malicious app to do so. If you have cases where a reasonably written app could be subverted through its use of JavaMail, please provide details. The input injection happens with the mail sending, developers that abstract mail should expect that when setSubject is passed an arbitrary string it will only set the subject. The injection vuln. lies in JavaMail. I do have a proof-of-concept against the educational platform Blackboard Learn - I selected this because I knew they used Java (I later proved that they used JavaMail). This application provides users with the capability of sending limited emails (in HTML, in sender address etc.). An attacker might use this vulnerability to change the sender address to anything (like admin@example.com). I verified that JavaMail was used through header inspection. The most recent time I inspected the source code was just before opening this bug. I don't think there's been a release between then and now. In the current state of JavaMail, unvalidated user input can and will allow a user to hijack the connection. This is not like SQL injection where the fault lies in poor or lacking implementations on the part of developers making calls to the database. CRLF hijacking is inherently mail-related. This is more similar to an attack o It is not reasonable to expect developers to validate mail-related input. If JavaMail abstracts Mail for the developer, then it should abstract mail security as well. It also should be noted that CRLF injection happens a lot with HTTP, and is considered a security vulnerability (CWE-93). Show me a sample program that uses the setSubject method to do CRLF injection, and indicate what version of JavaMail you're using. I believe the problem you describe was fixed in JavaMail 1.5.6 by this bug: https://github.com/eclipse-ee4j/javamail/issues/222 I did some digging around and found out that I was using a JavaMail library from several years ago, back when I was initially playing around with emailing via Java as part of an internship. I had downloaded the new API once i found the bug, but i had failed to update my build path. As such, the POC's I had written within Java worked. The POC's that made HTTP requests with a slightly different payload worked because the target code (written by a different vendor) also depended on an older version. When I traced the code on GitHub, I failed to inspect the behavior of the fold function - my mistake. Turns out this bug is not unique - I'm a solid 2 years too late. Sorry for wasting your time, and thanks for putting up with me! *** This bug has been marked as a duplicate of bug 7529 *** (In reply to Dhruv Gramopadhye from comment #8) > *** This bug has been marked as a duplicate of bug 7529 *** I'm pretty sure that this isn't true. It is a duplicate of this bug though: https://github.com/eclipse-ee4j/javamail/issues/222 "@glassfishrobot Commented This issue was imported from Bugzilla JAVAMAIL-7529" Given that there's no CVE for this, and that some people are still using a vulnerable version, I think it would be helpful for Eclipse to issue a CVE for this vulnerability. Blackboard Learn, for example, has been using an insecure version for quite some time without knowing that it was vulnerable because there was no CVE issued. Who knows who else hasn't updated their dependency yet? Not to mention, if a CVE is issued, the vulnerability will appear on automated code scanning tools like what GitHub has for vulnerabilities, and get developers to update dependencies. Better late than never? This was fixed in Blackboard Learn 9.1 Q4 2018, released on Oct 24, 2018 To issue a CVE, I need a committer from the project team to complete the steps described here: https://www.eclipse.org/projects/handbook/#vulnerability-cve If it is the opinion of the project team that no CVE is required, please mark this issue resolved. (In reply to Wayne Beaton from comment #14) > To issue a CVE, I need a committer from the project team to complete the > steps described here: > > https://www.eclipse.org/projects/handbook/#vulnerability-cve > > If it is the opinion of the project team that no CVE is required, please > mark this issue resolved. (In reply to Bill Shannon from comment #7) > Show me a sample program that uses the setSubject method to do CRLF > injection, > and indicate what version of JavaMail you're using. > > I believe the problem you describe was fixed in JavaMail 1.5.6 by this bug: > https://github.com/eclipse-ee4j/javamail/issues/222 Any opinions? Assuming this issue was addressed in JavaMail 1.5.6, then there's no version of the software at Eclipse that has this issue. Thus, I'm not sure why a CVE would be issued against the Eclipse software. (In reply to Bill Shannon from comment #16) > Assuming this issue was addressed in JavaMail 1.5.6, then there's no > version of the software at Eclipse that has this issue. Thus, I'm not > sure why a CVE would be issued against the Eclipse software. I want to ensure that the vulnerability is properly documented and classified so people that use JavaMail can react appropriately. If Eclipse was not the maintainer at the time, should we go to Oracle and ask them to issue a CVE for JavaMail? (In reply to Dhruv Gramopadhye from comment #17) > If Eclipse was not the maintainer at the time, should we go to Oracle and > ask them to issue a CVE for JavaMail? Even though I work at Oracle, I have no idea how to ask Oracle to issue a CVE, but that's probably the right thing to do. (In reply to Bill Shannon from comment #18) > (In reply to Dhruv Gramopadhye from comment #17) > > If Eclipse was not the maintainer at the time, should we go to Oracle and > > ask them to issue a CVE for JavaMail? > > Even though I work at Oracle, I have no idea how to ask Oracle to issue a > CVE, > but that's probably the right thing to do. I will make an effort to find the right points of contact for this. If you find anything out, please let me know! I will update you when I find the appropriate person. |