15:01:59 #startmeeting security 15:02:00 Meeting started Thu Aug 13 15:01:59 2020 UTC and is due to finish in 60 minutes. The chair is gagehugo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:03 The meeting name has been set to 'security' 15:02:21 ahoy, y'all 15:03:03 #link https://etherpad.opendev.org/p/security-agenda agenda 15:03:11 o/ 15:07:10 #topic https://bugs.launchpad.net/nova/+bug/1888722 15:07:12 Launchpad bug 1888722 in OpenStack Compute (nova) "The Nova api permits any possible hostname, including for example "../.." or "; --" or "hostname.openstack.org"" [Undecided,New] 15:07:58 this was one the vmt and nova devs basically considered not a bug 15:08:15 but some users find it surprising, so i felt it was worth calling out 15:08:32 So OSSN? 15:09:23 well, basically there's no obvious vulnerability here, though if people try to use instance names in places where those characters are dangerous, then that could be a risk 15:09:31 or just a warning I guess? 15:10:12 though one of the examples given was that of "." in instance names, the reporter seemed legitimately concerned about instances with names which looked like fqdns 15:10:34 i and others actually like to use fqdns as instance names, so this really seemed like a matter of personal taste 15:12:11 anyway, i figured i'd point this one out in case anyone has concerns similar to those of the reporter 15:12:35 the suggestion to disallow "." in instance names, for example, was dismissed fairly quickly 15:13:25 but also the idea of making a configurable filter for allowed characters was (rightly in my opinion) seen as hindering interoperability 15:14:48 hmm ok 15:15:35 #topic security issue - some command injection vulnerability found and fixed 15:15:45 #link https://bugs.launchpad.net/cinder/+bug/1889055 15:15:47 Launchpad bug 1889055 in OpenStack Security Advisory "security issue - some command injection vulnerability found and fixed" [Undecided,Invalid] 15:16:03 I see also invalid 15:19:07 yeah, this one was a good example of a researcher running code analysis on a repository and assuming a vulnerability without knowing how that part of the software was used 15:21:46 bugs like that serve as reminders that reports of suspected vulnerabilities without any idea of what the exploit scenario would be are not terribly useful, and we would much prefer folks research the bugs they think they've found before reporting them as suspected vulnerabilities 15:28:38 ah ok 15:28:50 #topic CVE-2020-11984 mod_proxy_uwsgi buffer overflow 15:30:01 #link https://httpd.apache.org/security/vulnerabilities_24.html 15:32:30 this was more a heads up, i know lots of openstack deployments utilize apache mod_proxy_uwsgi and this is a pretty significant remote exploit 15:33:00 this might be something someone who's interested in writing an ossn might be interested in tackling 15:33:52 #info CVE-2020-11984 may be a good opportunity for an OSSN to alert OpenStack deployers to potential risks in unpatched Apache mod_proxy_uwsgi 15:34:36 Do we cover non-openstack services? Or is that specific to OSSAs? 15:34:45 It makes sense imo 15:37:43 in the past we've used ossn to alert users to critical vulnerabilities in our dependencies 15:38:05 not often, but there are some examples in the record 15:38:18 ok cool 15:38:26 i think the most recent one was on spectre/meltdown 15:39:31 anyway, i just figured i'd bring it to the attention of meeting attendees or anyone reading the logs/minutes/summary, in case there's maybe a lurker who wants to get involved, since this could be a fairly easy one 15:40:10 feel free to hit us up in the #openstack-security channel on freenode or the openstack-discuss ml if there are questions about the ossn process 15:41:13 sounds good! 15:41:24 I need to run, thanks as always fungi! 15:41:27 #endmeeting