openvpn-devel Mailing List for OpenVPN

I do not mind about "the official repo". can you provide more details on that? 2015-08-01 18:07 GMT+05:00 Gert Doering <ge...@gr...>: > Hi, > > On Fri, Jul 31, 2015 at 11:57:26AM +0200, Samuel Thibault wrote: >> But without a central repository where people would get to know about >> your version, then it's even more probable that you'll remain the only >> user... > > Indeed. Who *is* maintaining the radius plugin these days? What is > "the official" repo? > > I found some stuff on > > http://www.nongnu.org/radiusplugin/ > > (no change since 2010, but the debian package has "more recent" updates, > and the ubuntu package even has a patch from Samuel Thibault :-) ) > > http://www.bytebucket.org/02strich/openvpn-auth-radius/src > > (this seems to be a fork, many of the files have the commit message > "initial commit - based on 2.1 Beta", but there has been a bit of activity > in 2012 and 2014... not very much, so merging the stuff back should not > be very hard) > > gert > > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany ge...@gr... > fax: +49-89-35655025 ge...@ne... 

Your patch has been applied to the master and release/2.3 branch. commit cc377dec820f9e6e7e72981013eb3857aa6ea5ce (master) commit 338f11821fa7ce95c768b0cc074f3af7346b19fa (release/2.3) Author: Steffan Karger Date: Wed Jul 29 12:30:26 2015 +0200 Fix overflow check in openvpn_decrypt() Signed-off-by: Steffan Karger <ste...@fo...> Acked-by: Arne Schwabe <ar...@rf...> Message-Id: <143...@fo...> URL: http://article.gmane.org/gmane.network.openvpn.devel/9974 Signed-off-by: Gert Doering <ge...@gr...> -- kind regards, Gert Doering 

Hi, On Fri, Jul 31, 2015 at 11:57:26AM +0200, Samuel Thibault wrote: > But without a central repository where people would get to know about > your version, then it's even more probable that you'll remain the only > user... Indeed. Who *is* maintaining the radius plugin these days? What is "the official" repo? I found some stuff on http://www.nongnu.org/radiusplugin/ (no change since 2010, but the debian package has "more recent" updates, and the ubuntu package even has a patch from Samuel Thibault :-) ) http://www.bytebucket.org/02strich/openvpn-auth-radius/src (this seems to be a fork, many of the files have the commit message "initial commit - based on 2.1 Beta", but there has been a bit of activity in 2012 and 2014... not very much, so merging the stuff back should not be very hard) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Am 01.07.15 um 13:03 schrieb ste...@fo...: > From: Steffan Karger <ste...@fo...> > > Sebastian Krahmer from the SuSE security team reported that the buffer > overflow check in openvpn_decrypt() was too strict according to the > cipher update function contract: > > "The amount of data written depends on the block alignment of the > encrypted data: as a result the amount of data written may be anything > from zero bytes to (inl + cipher_block_size - 1) so outl should contain > sufficient room." > > This stems from the way CBC mode works, which caches input and 'flushes' > it block-wise to the output buffer. We do allocate enough space for this > extra block in the output buffer for CBC mode, but not for CFB/OFB modes. > > This patch: > * updates the overflow check to also verify that the extra block required > according to the function contract is available. > * uses buf_inc_len() to double-check for overflows during en/decryption. > * also reserves the extra block for non-CBC cipher modes. > > In practice, I could not find a way in which this would fail. The plaintext > is never longer than the ciphertext, and the implementations of CBC/OFB/CBC > for AES and BF in both OpenSSL and PolarSSL/mbed TLS do not use the buffer > beyond the plaintext length when decrypting. However, some funky OpenSSL > engine I did not check *might* use the buffer space required by the > function contract. So we should still make sure we have enough room > anyway. > ACK from me. Arne