You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nico Kadel-Garcia <nk...@gmail.com> on 2014/04/11 05:53:14 UTC
Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
I was just realizing that no one has mentioned it here: For anyone
running HTTPS based Subversion servers, they should really take a good
look at whether their web server is vulnerable to the "HeartBleed"
security problem in OpenSSL. There are various good write-ups about
it, but even an internal website vulnerable to these hacks could
apparently have usernames and passwords stolen by a zombied or
rootkitted host inside your network. So strongly consider updating
*all* your websites to avoid the bug, and other bugs, and strongly
consider your password management and expiration procedures for
vulnerabilities that may have been exploited any time in the last two
years.
http://www.theatlantic.com/technology/archive/2014/04/how-to-check-if-a-site-is-safe-from-heartbleed/360417/
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Ben Reser <be...@reser.org>.
On 4/10/14, 9:53 PM, Nico Kadel-Garcia wrote:
> I was just realizing that no one has mentioned it here: For anyone
> running HTTPS based Subversion servers, they should really take a good
> look at whether their web server is vulnerable to the "HeartBleed"
> security problem in OpenSSL. There are various good write-ups about
> it, but even an internal website vulnerable to these hacks could
> apparently have usernames and passwords stolen by a zombied or
> rootkitted host inside your network. So strongly consider updating
> *all* your websites to avoid the bug, and other bugs, and strongly
> consider your password management and expiration procedures for
> vulnerabilities that may have been exploited any time in the last two
> years.
>
> http://www.theatlantic.com/technology/archive/2014/04/how-to-check-if-a-site-is-safe-from-heartbleed/360417/
For what it's worth we're preparing specific advice for admins (so much as we
can), but it is taking some time to complete largely because we lack much in
the way of handling revoked certificates. I hope to have something up later
today on the users@, dev@ and announce@ lists.
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Apr 11, 2014 at 03:52:57PM -0400, Nico Kadel-Garcia wrote:
> On Fri, Apr 11, 2014 at 6:08 AM, Hannes Erven <ha...@erven.at> wrote:
> > This is not entirely correct: any web server process with openssl-based SSL
> > enabled was vulnerable. So even if the repository itself wasn't
> > served on HTTPS, but some other vhost was, you're still affected.
>
> Do you have a pointer to that?
http://xkcd.com/1354/
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Apr 12, 2014 at 11:33:36AM -0700, Ben Reser wrote:
> On 4/12/14, 1:30 AM, Thorsten Schöning wrote:
> > Are you sure about that? From my understanding it is necessary that
> > data passes OpenSSL's memory to get retrieved because it implements
> > it's own malloc. I had the feeling that in case of heartbleed only
> > sending passwords over http would have been the "more secure" way
> > because in that case they wouldn't have been retrievable because they
> > never passed memory allocated using OPENSSL_malloc() at all.
>
> No that's not accurate at all. The malloc implementation doesn't matter at
> all, the process can read memory that's allocated by any memory allocator.
> Ultimately all of them have to use the same kernel interfaces to request the
> memory.
>
> The requirements are that the memory be allocated in a larger memory address
> than the memory being used for the heartbeat feature and that it be within 64k
> of that memory space. With memory fragmentation and a lot of requests just
> about anything can be retrieved.
One point raised about malloc is that some malloc implementations
might put junk into freed memory space. So the application would
read junk when reading past the (shorter than specified) payload data.
Instead of a chunk of memory that looks like this:
0................................64k
[hearbeat payload; interesting data]
you'd have something like his:
0..............................64k
[hearbeat payload; junk junk junk]
But since OpenSSL doesn't actually ask the OS to free the memory
before reusing it this mitigation strategy was ineffective.
See http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
So I asked myself the same question about APR pools and found that
APR pool debugging does exactly this. It overwrites pool memory with
a junk byte (0x41) when the pool is cleared or destroyed.
I've now enabled pool debugging by default for OpenBSD's APR packages.
This might cause a performance hit. But in case Subversion or HTTPD ever
have a similar problem it will be mitigated on OpenBSD.
I'm not sure how many SVN/HTTPD deployments run on OpenBSD servers though,
and how much performance matters for them vs mitigation. I'll be watching
for user feedback about this change.
Another point is guard pages, i.e. holes in address space created by
malloc, so the application would segfault when trying to read memory
within the hole.
0...............................................64k
[hearbeat payload] NOT MAPPED [interesting data]
It has been suggested various times that this would have defeated
heartbleed if it were not for OpenSSL's malloc. However, it seems that
in practice this situation didn't occur for the small buffers used by
the heartbeat code, at least not with OpenBSD's malloc. (Again, see the
above link.)
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Mon, Apr 14, 2014 at 1:47 PM, Ben Reser <be...@reser.org> wrote:
> On 4/12/14, 3:41 PM, Nico Kadel-Garcia wrote:
>> For our own safety and benefito of combined HTTP/HTTPS servers for
>> Subversion worldwide: is there a published test to verify that HTTP
>> servers do not have the same flaw due to also being configured for
>> SSL?
>
> Stefan Sperling replied to you on the dev list already, but I think it's worth
> answering here again since there's a different audience here.
>
> A HTTP server that has no ports enabled to use SSL but that has mod_ssl is not
> vunlerable. This is the case because the issue only occurs when using the
> heartbeat extension of TLS (which requires an SSL/TLS enabled connection).
>
> However, servers that have both HTTP and HTTPS ports enabled may leak
> information about the HTTP only traffic via the HTTPS connections. I wouldn't
> be surprised if people have servers with public facing connections that are SSL
> enabled but internal only connections that do not use SSL at all.
But they're not leaking it over the HTTP port connections, even on a
vulnerable server that is HTTPS enabled, which is certainly not
unheard of. People host public spaces via HTTP on hosts that have
internal, administrative services like Nagios or Subversion, with
HTTPS "write" access exposed only internally.
> Consider this scenario. You have a public website with SSL enabled and a SVN
> repository (not SSL enabled) that's only accessible on your own private network
> (probably even on private address space). You are using the same httpd
> instance to host both. It is possible that information ranging from
> authentication details, tree structure, to even full file contents can be
> leaked by the SSL connection about the HTTP SVN connections.
Oh, yes, and I'm not discounting the risk of internally root-kitted or
zombied hosts scanning the internal SSL traffic.
> Essentially anything in memory of a process utilizing a vulnerable version of
> OpenSSL to implement the heartbeat extension to TLS is subject to being
> revealed to clients of the TLS connections.
>
>
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Ben Reser <be...@reser.org>.
On 4/12/14, 3:41 PM, Nico Kadel-Garcia wrote:
> For our own safety and benefito of combined HTTP/HTTPS servers for
> Subversion worldwide: is there a published test to verify that HTTP
> servers do not have the same flaw due to also being configured for
> SSL?
Stefan Sperling replied to you on the dev list already, but I think it's worth
answering here again since there's a different audience here.
A HTTP server that has no ports enabled to use SSL but that has mod_ssl is not
vunlerable. This is the case because the issue only occurs when using the
heartbeat extension of TLS (which requires an SSL/TLS enabled connection).
However, servers that have both HTTP and HTTPS ports enabled may leak
information about the HTTP only traffic via the HTTPS connections. I wouldn't
be surprised if people have servers with public facing connections that are SSL
enabled but internal only connections that do not use SSL at all.
Consider this scenario. You have a public website with SSL enabled and a SVN
repository (not SSL enabled) that's only accessible on your own private network
(probably even on private address space). You are using the same httpd
instance to host both. It is possible that information ranging from
authentication details, tree structure, to even full file contents can be
leaked by the SSL connection about the HTTP SVN connections.
Essentially anything in memory of a process utilizing a vulnerable version of
OpenSSL to implement the heartbeat extension to TLS is subject to being
revealed to clients of the TLS connections.
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
For our own safety and benefito of combined HTTP/HTTPS servers for
Subversion worldwide: is there a published test to verify that HTTP
servers do not have the same flaw due to also being configured for
SSL?
On Sat, Apr 12, 2014 at 2:33 PM, Ben Reser <be...@reser.org> wrote:
> On 4/12/14, 1:30 AM, Thorsten Schöning wrote:
>> Are you sure about that? From my understanding it is necessary that
>> data passes OpenSSL's memory to get retrieved because it implements
>> it's own malloc. I had the feeling that in case of heartbleed only
>> sending passwords over http would have been the "more secure" way
>> because in that case they wouldn't have been retrievable because they
>> never passed memory allocated using OPENSSL_malloc() at all.
>
> No that's not accurate at all. The malloc implementation doesn't matter at
> all, the process can read memory that's allocated by any memory allocator.
> Ultimately all of them have to use the same kernel interfaces to request the
> memory.
>
> The requirements are that the memory be allocated in a larger memory address
> than the memory being used for the heartbeat feature and that it be within 64k
> of that memory space. With memory fragmentation and a lot of requests just
> about anything can be retrieved.
>
>
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Ben Reser <be...@reser.org>.
On 4/12/14, 1:30 AM, Thorsten Schöning wrote:
> Are you sure about that? From my understanding it is necessary that
> data passes OpenSSL's memory to get retrieved because it implements
> it's own malloc. I had the feeling that in case of heartbleed only
> sending passwords over http would have been the "more secure" way
> because in that case they wouldn't have been retrievable because they
> never passed memory allocated using OPENSSL_malloc() at all.
No that's not accurate at all. The malloc implementation doesn't matter at
all, the process can read memory that's allocated by any memory allocator.
Ultimately all of them have to use the same kernel interfaces to request the
memory.
The requirements are that the memory be allocated in a larger memory address
than the memory being used for the heartbeat feature and that it be within 64k
of that memory space. With memory fragmentation and a lot of requests just
about anything can be retrieved.
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Ben Reser,
am Samstag, 12. April 2014 um 01:10 schrieben Sie:
> As such even if you only have your Subversion repository running over
> HTTP, if you have SSL enabled for some other purpose, your Subversion related
> data in memory might be exposed.
Are you sure about that? From my understanding it is necessary that
data passes OpenSSL's memory to get retrieved because it implements
it's own malloc. I had the feeling that in case of heartbleed only
sending passwords over http would have been the "more secure" way
because in that case they wouldn't have been retrievable because they
never passed memory allocated using OPENSSL_malloc() at all.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Apr 11, 2014 at 10:26 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Fri, Apr 11, 2014 at 7:10 PM, Ben Reser <be...@reser.org> wrote:
>> On 4/11/14, 12:52 PM, Nico Kadel-Garcia wrote:
>>> Do you have a pointer to that? It's a reasonable claim, I'd just not
>>> seen anything for verifying it or testing against HTTP sites that have
>>> HTTPS enabled, perhaps even with HTTPS only accessible behind a
>>> closed firewall for administrative user
>>
>> Apache HTTP Server can respond to multiple ports, some of which may be SSL
>> enabled and some of which that many not. The same processes are used for
>> either. As such even if you only have your Subversion repository running over
>> HTTP, if you have SSL enabled for some other purpose, your Subversion related
>> data in memory might be exposed.
Sorry for the blank reply. The SSL based services, when managed by
Apache, are normally handled by a different "VirtualHost" setting, but
yes, you're right.. The same daemon and child processes have the SSL
module loaded.
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Apr 11, 2014 at 7:10 PM, Ben Reser <be...@reser.org> wrote:
> On 4/11/14, 12:52 PM, Nico Kadel-Garcia wrote:
>> Do you have a pointer to that? It's a reasonable claim, I'd just not
>> seen anything for verifying it or testing against HTTP sites that have
>> HTTPS enabled, perhaps even with HTTPS only accessible behind a
>> closed firewall for administrative user
>
> Apache HTTP Server can respond to multiple ports, some of which may be SSL
> enabled and some of which that many not. The same processes are used for
> either. As such even if you only have your Subversion repository running over
> HTTP, if you have SSL enabled for some other purpose, your Subversion related
> data in memory might be exposed.
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Ben Reser <be...@reser.org>.
On 4/11/14, 12:52 PM, Nico Kadel-Garcia wrote:
> Do you have a pointer to that? It's a reasonable claim, I'd just not
> seen anything for verifying it or testing against HTTP sites that have
> HTTPS enabled, perhaps even with HTTPS only accessible behind a
> closed firewall for administrative user
Apache HTTP Server can respond to multiple ports, some of which may be SSL
enabled and some of which that many not. The same processes are used for
either. As such even if you only have your Subversion repository running over
HTTP, if you have SSL enabled for some other purpose, your Subversion related
data in memory might be exposed.
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Apr 11, 2014 at 6:08 AM, Hannes Erven <ha...@erven.at> wrote:
> Hi all,
>
>
>
> Daniel Shahaf wrote:
>>
>> Nico Kadel-Garcia wrote on Thu, Apr 10, 2014 at 23:53:14 -0400:
>>>
>>> I was just realizing that no one has mentioned it here: For anyone
>>> running HTTPS based Subversion servers, they should really take a good
>>> look at whether their web server is vulnerable to the "HeartBleed"
>>> security problem in OpenSSL.
>>
>>
>> Repositories served exclusively with http:// (non-SSLed), svn+ssh://,
>> and/or svn://-with-SASL-disabled are not affected.
>
>
> This is not entirely correct: any web server process with openssl-based SSL
> enabled was vulnerable. So even if the repository itself wasn't
> served on HTTPS, but some other vhost was, you're still affected.
Do you have a pointer to that? It's a reasonable claim, I'd just not
seen anything for verifying it or testing against HTTP sites that have
HTTPS enabled, perhaps even with HTTPS only accessible behind a
closed firewall for administrative user.
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Hannes Erven <ha...@erven.at>.
Hi all,
Daniel Shahaf wrote:
> Nico Kadel-Garcia wrote on Thu, Apr 10, 2014 at 23:53:14 -0400:
>> I was just realizing that no one has mentioned it here: For anyone
>> running HTTPS based Subversion servers, they should really take a good
>> look at whether their web server is vulnerable to the "HeartBleed"
>> security problem in OpenSSL.
>
> Repositories served exclusively with http:// (non-SSLed), svn+ssh://,
> and/or svn://-with-SASL-disabled are not affected.
This is not entirely correct: any web server process with openssl-based
SSL enabled was vulnerable. So even if the repository itself wasn't
served on HTTPS, but some other vhost was, you're still affected.
Best regards,
-hannes
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nico Kadel-Garcia wrote on Thu, Apr 10, 2014 at 23:53:14 -0400:
> I was just realizing that no one has mentioned it here: For anyone
> running HTTPS based Subversion servers, they should really take a good
> look at whether their web server is vulnerable to the "HeartBleed"
> security problem in OpenSSL.
Repositories served exclusively with http:// (non-SSLed), svn+ssh://,
and/or svn://-with-SASL-disabled are not affected.
As to svn://-with-SASL, libsasl can optionally link against libssl, but
I'm not sure whether it can trigger the vulnerable codepath.
svn:// over stunnel would be affected too --- just in case someone
is using that.
Daniel
> There are various good write-ups about
> it, but even an internal website vulnerable to these hacks could
> apparently have usernames and passwords stolen by a zombied or
> rootkitted host inside your network. So strongly consider updating
> *all* your websites to avoid the bug, and other bugs, and strongly
> consider your password management and expiration procedures for
> vulnerabilities that may have been exploited any time in the last two
> years.
>
> http://www.theatlantic.com/technology/archive/2014/04/how-to-check-if-a-site-is-safe-from-heartbleed/360417/