<div dir="ltr">Thank you for the information - I appreciate the work, and the follow-up. This was very helpful, and should make our process much smoother. Thanks to you, and all other active developers, for the work you've all done on Cyrus!<div><br></div><div>Tim</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 5:37 PM, ellie timoney via Info-cyrus <span dir="ltr"><<a href="mailto:info-cyrus@lists.andrew.cmu.edu" target="_blank">info-cyrus@lists.andrew.cmu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div><div>Hi Tim,<br></div>
<div> </div>
<div>Yeah, those are the correct two commits.</div><span class="">
<div> </div>
<blockquote type="cite"><blockquote><div dir="ltr"><div>My other concern was that, honestly, I'm not all that sure what the true risk and capability to exploit is for these bugs. I've read the CVE's, and associated discussions on the a few lists - but it hasn't enlightened me as much as I've hoped.<br></div>
<div> </div>
</div>
</blockquote></blockquote><div> </div>
</span><div>As I understand it, the vulnerability was that someone (with enough access to make a urlfetch request and not have it refused for lack of auth) could trick the server into returning more data than the requested resource actually contained, with contents of memory leaking into the extra. I don't know whether it could contain anything predictable, useful or "interesting". If the range they asked for crossed an allocation boundary, I think they'd probably just trigger a SEGV in the process serving their connection, and be disconnected.<br></div>
<div> </div>
<div>I don't know much about urlfetch in practice, or this implementation in particular, so I too don't really know how exploitable this is. The bug just happened to cross my radar, so it got whacked.<br></div>
<div> </div>
<div>Cheers,<br></div>
<div> </div>
<div>ellie</div><div><div class="h5">
<div> </div>
<div>On Tue, Dec 15, 2015, at 03:36 AM, Tim Champ via Info-cyrus wrote:<br></div>
</div></div><blockquote type="cite"><div><div class="h5"><div dir="ltr"><div>Hello all. Sorry about following up to my own email, but I think I understand the changes now to 2.4.18 in order to make it CVE compliant. As best I can understand, if I apply the two commits from Ellie Timoney on 10/26/2015, 2.4.18 would be "secure" once recompiled. These two commits appear to be these:<br></div>
<div> </div>
<div><a href="https://cyrus.foundation/cyrus-imapd/commit/?h=cyrus-imapd-2.4&id=538359e5a7c978e2f27c80124c8bd1282c7661a9" target="_blank">https://cyrus.foundation/cyrus-imapd/commit/?h=cyrus-imapd-2.4&id=538359e5a7c978e2f27c80124c8bd1282c7661a9</a><br></div>
<div> </div>
<div><a href="https://cyrus.foundation/cyrus-imapd/commit/?h=cyrus-imapd-2.4&id=0142e98fa90f02a030f93469523ac64f91ae7a9f" target="_blank">https://cyrus.foundation/cyrus-imapd/commit/?h=cyrus-imapd-2.4&id=0142e98fa90f02a030f93469523ac64f91ae7a9f</a><br></div>
<div> </div>
<div><div>If someone can confirm that I'm correct on this, it would be very appreciated! Thanks in advance.<br></div>
<div> </div>
<div>Tim<br></div>
</div>
</div>
<div><div> </div>
<div><div>On Mon, Dec 14, 2015 at 11:04 AM, Tim Champ <span dir="ltr"><<a href="mailto:champ@umbc.edu" target="_blank">champ@umbc.edu</a>></span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Hello all.<br></div>
<div> </div>
<div>We're trying to sort through our path here with patching for the CVE/commits that were released in 2.5.7, but also relevant to 2.4.18. We're currently on 2.4 series, and I was wondering what the plans were for a 2.4 release to address these security fixes. While moving to 2.5 is in the plans, I always despise a quick upgrade of anything before major holiday periods!<br></div>
<div><div> </div>
<div>My other concern was that, honestly, I'm not all that sure what the true risk and capability to exploit is for these bugs. I've read the CVE's, and associated discussions on the a few lists - but it hasn't enlightened me as much as I've hoped.<br></div>
</div>
<div><div> </div>
<div>Any help, or answers, for either issue is appreciated. Thanks!<span><span style="color:rgb(136,136,136)"><br><br>Tim<br clear="all"></span></span></div>
<div> </div>
<div><span><span style="color:rgb(136,136,136)">-- <br></span></span></div>
<div><div dir="ltr"><span><span style="color:rgb(136,136,136)">Tim Champ<br>Coordinator of Unix Infrastructure<br>UMBC - Division of Information Technology</span></span></div>
</div>
<div> </div>
</div>
</div>
</blockquote></div>
<div> </div>
<div> </div>
<div> </div>
<div>-- <br></div>
<div><div dir="ltr"><div>Tim Champ<br></div>
<div>Coordinator of Unix Infrastructure<br></div>
<div>UMBC - Division of Information Technology<br></div>
</div>
</div>
</div>
</div></div><div>----<br></div>
<div>Cyrus Home Page: <a href="http://www.cyrusimap.org/" target="_blank">http://www.cyrusimap.org/</a><br></div>
<div>List Archives/Info: <a href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/" target="_blank">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a><br></div>
<div>To Unsubscribe:<br></div>
<div><a href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus" target="_blank">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a><br></div>
</blockquote><div> </div>
</div>
<br>----<br>
Cyrus Home Page: <a href="http://www.cyrusimap.org/" rel="noreferrer" target="_blank">http://www.cyrusimap.org/</a><br>
List Archives/Info: <a href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/" rel="noreferrer" target="_blank">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a><br>
To Unsubscribe:<br>
<a href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus" rel="noreferrer" target="_blank">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Tim Champ<br>Coordinator of Unix Infrastructure<br>UMBC - Division of Information Technology</div></div>
</div>