https://bugs.kde.org/show_bug.cgi?id=432353
Jan Kundrát <j...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|REPORTED |CONFIRMED
--- Comment #3 from Jan Kundrát <j...@kde.org> ---
> Trojita accepts LIST, LSUB, STATUS, ... untagges responses before STARTTLS
> and incorporates them into local state.
>
> I am not sure if this is already kind of a misbehavior even without
> STARTTLS, because the IMAP RFC does not really prohibit that. However, a
> meddler in the middle can use this to tamper with the state of Trojita.
Thanks for finding this, and sorry for not responding earlier. You're right,
this can inject info about non-existing mailboxes (which will disappear after a
reconnect), it can cause extra bandwidth consumption (due to syncing more than
what is strictly needed to transfer), and it also has a Denial-of-Service
potential (e.g., if the attacker pushes nonsense, the UID syncing code will ask
the user to clear cache and refuse to proceed beforehand).
> This *could* also be escalated to a more severe issue. E.g. when an attacker
> injects a folder name with "\r\n<tag> <command>", it could trick Trojita to
> execute attacker-controlled commands on the IMAP server after login.
>
> The only thing preventing this is sanitization of folder names, but I am not
> sure if we should count on that...
This cannot be exploited like that. Since IMAP is a text-based protocol, there
are rules on how to "intervene" user-controlled (or even attacker-controlled)
strings with protocol commands. However, this is not specific to a possible
side-channel injection due to STARTTLS. The real user can just as well create a
mailbox which has a newline in its name, and the IMAP code must handle this
properly. Let's not call this "sanitization", please; it's a critical part of
implementing a protocol. The STARTTLS vulnerability will only be relevant in
this context if the attacker-controlled cache stored strings which are somehow
escaped, and that is not the case.
--
You are receiving this mail because:
You are watching all bug changes.
