<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">--</div><div class="">Lance Cottrell</div><div class=""><a href="mailto:loki@obscura.com" class="">loki@obscura.com</a></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On May 28, 2019, at 4:27 PM, Grant Taylor <<a href="mailto:gtaylor@tnetconsulting.net" class="">gtaylor@tnetconsulting.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 5/28/19 11:07 AM, Lance Cottrell wrote:<br class=""><blockquote type="cite" class="">The decrypted message will eventually be sent in the clear, that is with that remailer’s layer of encryption removed.<br class=""></blockquote><br class="">Agreed.<br class=""><br class="">/Eventually/ being the operative word. As such, there is a timing component to the attack. Meaning that either the sniffer needs to be ongoing. If it's not ongoing, then there is a smaller time window.<br class=""><br class="">It's an exposure. I don't know how important it is.<br class=""></div></div></blockquote><div><br class=""></div><div>So, we have two choices, store the message encrypted, which will match the known incoming message and can be decrypted to see the outgoing, or we can store the decrypted message and have no stored information about which incoming message it was related to. The later sounds better to me.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">Having only the decrypted versions stored means that an attacker would have more difficulty seeing which incoming encrypted email corresponds to each decrypted outgoing email.<br class=""></blockquote><br class="">How so?<br class=""><br class="">Are you implying that an attacker could get the keys and decrypt the message to see the encrypted and decrypted? Where as if it's decrypted, it's much more difficult to see the encrypted counterpart?<br class=""></div></div></blockquote><div><br class=""></div><div>I am implying that an attacker with access to the drive probably has access to keys, memory, etc.</div><div><br class=""></div><div>Yes, that is exactly the conclusion.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">Generally, if an attacker owns your box, there is trouble. It is likely that they could get encryption keys and all the rest.<br class=""></blockquote><br class="">Agreed.<br class=""><br class="">I'm more thinking about the possibility of a misconfiguration / privilege escalation that would allow another non-privileged user to access the pool somehow. Say after an admin naively does a chmod -R 777 / or some such ill-advised activity.<br class=""><br class=""><blockquote type="cite" class="">Can you describe the attack and revealed information that this issue would allow, but which would not expose much worse at the same time?<br class=""></blockquote><br class="">No, I don't have an example (save for the chmod above). I'm more thinking out loud ~> discussing.<br class=""><br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Ok, I see where you are coming from. If this is an ongoing situation, then the attacker can probably get exact mapping between incoming and outgoing messages by watching them in real time on the disk. This is effectively a compromised node.</div><div><br class=""></div><div>For chmod to be a problem, Mixmaster needs to be running on a multi-tenant server along with untrusted other users. That is a bad situation already. Given a privilege escalation attack, they can probably start modifying the code, and grabbing all sorts of info. It seems like an edge case where they just get limited access to the files in the pool.</div><div><br class=""></div><div>Ideally, the operator will discover and fix this. It is also why one should use a good number of hops.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>-Lance</div><div><br class=""></div><div><br class=""></div></div></body></html>