<div dir="ltr">Configuration is created automatically by puppet, isn't it? <div>Does it also include automated tests for this scenarios? If not - why? </div><div>Thorough automated tests would have eliminated such mistakes.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div style="font-size:12.8px"><div><font color="#000000">Regards,</font></div><div><font color="#000000">[[User:Ilya]]</font></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Feb 22, 2016 at 5:46 AM, Andrew Bogott <span dir="ltr"><<a href="mailto:abogott@wikimedia.org" target="_blank">abogott@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- tl;dr<br>
<br>
We discovered a serious security vulnerability on toollabs. The vulnerability is now closed, and there’s no evidence that it was exploited. Nevertheless if you have private passwords stored on a toollabs host, change them!<br>
<br>
<br>
- Rambling explanation<br>
<br>
Earlier today it was pointed out to me that sudo policies within Toollabs were overly permissive -- any user with a tools login was able to sudo and potentially change their identity to root or to another user. I've identified the cause of the vulnerability (my fault!) and closed it; the incorrect policies were in effect from February 12th until earlier today.<br>
We have already investigated the 'to root' scenario and confirmed that it's unlikely that any labs nodes are compromised -- even the bastion-01 case is unlikely, but best to err on the side of caution.<br>
I have not yet audited the 'user becoming a different user' case -- that will be a big job and will most likely take much of the day tomorrow. Even if the audit turns up nothing, though, it's technically possible that someone might have snooped and later covered their tracks. Given that, I recommend rotation of any passwords that provide access to sensitive data.<br>
<br>
<br>
- What about other labs projects?<br>
<br>
Most labs projects have permissive sudo policies by default. A few have locked down policies, and those projects have been closely checked. Nonetheless, for completeness here are projects that were temporarily less secure: 'catgraph', 'translatesvg', 'toolsbeta', 'jawiki', 'wmve-techteam', 'utrs', 'wmt', 'bastion', 'project-proxy', 'mediawiki-verp', 'glam', 'wlmjudging', 'tools', 'account-creation-assistance'<br>
Note that this vulnerability did not allow any user to access hosts they were not authorized to -- project membership was properly enforced.<br>
<br>
<br>
Sorry for the inconvenience!<br>
<br>
-Andrew<br>
<br>
_______________________________________________<br>
Labs-announce mailing list<br>
<a href="mailto:Labs-announce@lists.wikimedia.org" target="_blank">Labs-announce@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/labs-announce" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/labs-announce</a><br>
_______________________________________________<br>
Labs-l mailing list<br>
<a href="mailto:Labs-l@lists.wikimedia.org" target="_blank">Labs-l@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/labs-l" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/labs-l</a><br>
</blockquote></div><br></div></div>