Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • mutt mutt
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 71
    • Issues 71
    • List
    • Boards
    • Service Desk
    • Milestones
    • Requirements
  • Merge requests 8
    • Merge requests 8
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Mutt Project
  • muttmutt
  • Issues
  • #248
Closed
Open
Created Jun 16, 2020 by Damian Poddebniak@duesee

Response Injection via STARTTLS in SMTP, POP3 and IMAP

We found another STARTTLS-related issue in Mutt. Unfortunately, it affects SMTP, POP3 and IMAP.

When the server responds with its "let's do TLS now message", e.g. A OK begin TLS\r\n in IMAP or +OK begin TLS\r\n in POP3, Mutt will also read any data after the \r\n and save it into some internal buffer for later processing. This is problematic, because a MITM attacker can inject arbitrary responses. I havn't tested it to this extent, but I highly suspect that this is enough to forge an entire new mailbox in POP3 and IMAP.

There is a nice blogpost by Wietse Venema about a "command injection" in postfix (http://www.postfix.org/CVE-2011-0411.html). What we have here is the problem in reverse, i.e. not a command injection, but a "response injection."

May I send you some more config.ron files (with a short explanation) you can use to test this with the server you already used in the PREAUTH issue via email?

Example trace to give an intuition:

C: A starttls\r\n
S: A OK begin TLS\r\n
   B OK you are logged in // injected response
<--- TLS --->
C: B login xxx xxx
// here, Mutt interprets the injected response and proceeds with something else
// an attacker can also already inject more responses and (in the worst case) mimic a whole session 
C: C select inbox
...
Edited Jun 16, 2020 by Damian Poddebniak
Assignee
Assign to
Time tracking