Re: [Ryu-devel] CVE-2018-1000155: Denial of Service, Improper Authentication and, Authorization, and Covert Channel in the OpenFlow 1.0+ handshake
On Thu, 17 May 2018 18:23:09 +0900, Kashyap Thimmaraju wrote: > > Dear Ryu Developers, > > I hope that you are aware of the OpenFlow CVE that was recently made > public [1]. Have there been any discussions on this? Do you plan to > provide a fix or announce a security advisory on this matter? We believe > it is important to spread the awareness to people using OpenFlow > controllers that such an attack is possible. > > [1] http://www.openwall.com/lists/oss-security/2018/05/09/4 > Thanks for notifying the vulnerability. I'll add a security note for the issue. With ryu, custom datapath id validation can be done by implementing an event handler for EventOFPSwitchFeatures. As there seems to be no standard way of doing such validation, it's basically up to ryu users for now. -- IWAMOTO Toshihiro -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
Re: [Ryu-devel] CVE-2018-1000155: Denial of Service, Improper Authentication and, Authorization, and Covert Channel in the OpenFlow 1.0+ handshake
I think a naming convention may work but in the case of plaintext CN it totaly forbids the operator of using self-signed certificates. Regarding secret HMAC based naming i think it may work even with self-signed certificates but then the security depends on more factors for example whether one switch can gain access to HMACs transmitted by other switches and how hard it is to correlate them with the switches IDs (e.g., by bruteforce or some heuristic on ids allocation). So I think the original solution is more easy regarding its requirements from the operator. On Fri, May 18, 2018, 01:26 William Fisher wrote: > It sounds like a single compromised switch peer certificate can be used to > impersonate other datapath_id's. > > From the advisory, it appears the controller-side fix is to verify the > datapath_id received in the FeaturesReply against the peer cert before > trusting it. > > Is it possible to use a naming convention that encodes the datapath_id in > the switch certificate's subject CN? This could be plaintext (exposing the > datapath_id in the clear during TLS handshake) or an HMAC of the > datapath_id using a secret that only the controller knows. > > Or, does the controller have to maintain the complete datapath_id to peer > cert blob mapping? (Assume that the controller already does whitelist by > datapath_id.) > > On Thu, May 17, 2018 at 2:54 AM Kashyap Thimmaraju < > kashyap.thimmar...@sect.tu-berlin.de> wrote: > > > Dear Ryu Developers, > > > I hope that you are aware of the OpenFlow CVE that was recently made > > public [1]. Have there been any discussions on this? Do you plan to > > provide a fix or announce a security advisory on this matter? We believe > > it is important to spread the awareness to people using OpenFlow > > controllers that such an attack is possible. > > > [1] http://www.openwall.com/lists/oss-security/2018/05/09/4 > > > -- > > Thanks, > > > Kashyap Thimmaraju > > Security in Telecommunications > > Technische Universität Berlin > > Ernst-Reuter-Platz 7, Sekr TEL 17 > > 10587 Berlin, Germany > > Phone: +49 30 8353 58351 > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > Ryu-devel mailing list > > Ryu-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/ryu-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
Re: [Ryu-devel] CVE-2018-1000155: Denial of Service, Improper Authentication and, Authorization, and Covert Channel in the OpenFlow 1.0+ handshake
It sounds like a single compromised switch peer certificate can be used to impersonate other datapath_id's. From the advisory, it appears the controller-side fix is to verify the datapath_id received in the FeaturesReply against the peer cert before trusting it. Is it possible to use a naming convention that encodes the datapath_id in the switch certificate's subject CN? This could be plaintext (exposing the datapath_id in the clear during TLS handshake) or an HMAC of the datapath_id using a secret that only the controller knows. Or, does the controller have to maintain the complete datapath_id to peer cert blob mapping? (Assume that the controller already does whitelist by datapath_id.) On Thu, May 17, 2018 at 2:54 AM Kashyap Thimmaraju < kashyap.thimmar...@sect.tu-berlin.de> wrote: > Dear Ryu Developers, > I hope that you are aware of the OpenFlow CVE that was recently made > public [1]. Have there been any discussions on this? Do you plan to > provide a fix or announce a security advisory on this matter? We believe > it is important to spread the awareness to people using OpenFlow > controllers that such an attack is possible. > [1] http://www.openwall.com/lists/oss-security/2018/05/09/4 > -- > Thanks, > Kashyap Thimmaraju > Security in Telecommunications > Technische Universität Berlin > Ernst-Reuter-Platz 7, Sekr TEL 17 > 10587 Berlin, Germany > Phone: +49 30 8353 58351 -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Ryu-devel mailing list > Ryu-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ryu-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
