Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
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.schoen...@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
On Fri, Apr 11, 2014 at 10:26 PM, Nico Kadel-Garcia wrote: > On Fri, Apr 11, 2014 at 7:10 PM, Ben Reser 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.
Restricting repository access with authz
I have an Apache server running mod_dav_svn and mod_authz_svn with several repositories, each with several projects which each contain the “typical 3” folders, where /svn is the base SVN path for access via HTTPS*. Kind of like this: /svn repository1 project1 branches tags trunk project2 … repository2 … What I want is to control access based on project. For example, I have this svnaccess file for authz (only relevant parts shown): [repository1:/project1] @project1users = r @project1admins = rw [repository1:/project1/trunk] @project1users = rw This works well enough. However, I’d also like users to be able to navigate into their allowed locations using the web interface. If I gave everyone read access to [/] then they could see the repositories. But that would allow them to read the contents of everything as well. Is there a way to allow users to see certain repositories in the list without giving recursive read access, for example, so that @project1users can navigate to the site in a browser, click “repository1”, then “project1”, then “trunk” without seeing “project2” or “repository2” or being able to access them? I wish there was something like this: (Note: If you want feel free to stop here, or maybe forward the rest of this to the developer mailing list or something.) [/] * = l [repository1:/] @project1users = vl [repository1:/project1] … @project1users = v where “l” stands for “list” which will allow a user to see visible directories within it, and “v” stands for “view” which will make it visible in listings for the parent. These would be applied NON-RECURSIVELY. So this would mean, combined with the previous access file: - The / root would be “listable” which would show viewable subdirectories. - Repository1:/ would be “viewable” so it would appear in the listing for / even though it’s not otherwise accessible. - Navigating into repository1 would not be readable. However, it would be “listable”. The subfolder project1 would be “viewable” which means it, and it alone, would appear in the listing for repository1. - Navigating into project1 would be covered by rw permissions. You wouldn’t even need “l” - you could just use the visibility specifier. Additionally, you could implement it so that “v” actually traces backwards. So if this was the case you could just do: [repository1:/project1] … @project1users = v In that case, the root listing would see that those users should be able to see /project1 so it would allow them to see and click on repository1 and project1 to get to it. There’s another way this could be implemented without any additional options - if there was a way to apply rw permissions non-recursively. (Well, technically it would still be a new option, but I digress). This would be close, but not quite the same, as the “lv” extensions. Let’s say something like rw* is non-recursive. [/] * = r* [repository1:/] @project1users = r* [repository1:/project1] @project1users = r @project1admins = rw [repository1:/project1/trunk] @project1users = rw Now, root would be readable, but clicking on any other repository would result in an error. The root of repository 1 would be readable, so @project1users could click through to project1, but clicking on project2 would throw an error. I kind of like the second option, where “v” indicates viewability and it applies to the parent path, allowing the user to click through to the directory, but there are a lot of different ways to do it. Maybe this would be something to add to the feature list for Subversion 2, whenever that ends up coming out. :) *Yes, if you’re wondering, I’ve tested for Heartbleed, and this server is secure. :)
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
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
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: 064k [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
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 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. > >
Subversion and Heartbleed
As you may have heard in the news OpenSSL has had a significant security vulnerability [1] [2]. Subversion by way of several of our dependencies uses OpenSSL. On the client side the Neon and Serf HTTP libraries can use OpenSSL (Neon can also use GNUTLS, which is not vulnerable to this issue) and on the server side Apache HTTP Server and Cyrus SASL can use OpenSSL (though Cyrus SASL's use of OpenSSL is not vulnerable). As a result it is important to make sure that the OpenSSL version being used with Subversion is not vulnerable. It is impossible for the Subversion project to provide vulnerable version information for Subversion since if you are vulnerable depends on the OpenSSL used at build and/or run time. We do not publish binaries, so you should consult with your binary provider to make sure you are not vulnerable. If you've built your own version of Subversion you should check which version you have built against and/or are using at runtime. This specific issue lies in the implementation of a feature of the SSL/TLS protocols. Apache HTTP Servers running mod_ssl to provide SSL/TLS are vulnerable. While svnserve does support encryption via Cyrus SASL, and Cyrus SASL does use OpenSSL to provide the encryption algorithms, it does not use it to implement the SSL/TLS protocols. This means that svnserve is not directly vulnerable. However, you can use the svnserve over tunnels and those tunnels may be vulnerable. For instance stunnel implements the SSL/TLS protocol and does so via OpenSSL. SSH based tunnels are unaffected as they do not use the SSL/TLS protocols. If you're using some other tunnel not mentioned here you should check with the developers of that tunnel for details. It is important to understand that this vulnerability is not specific to the server side. Clients can be vulnerable to malicious servers using the same attack against clients. So care should be taken to ensure that clients are not using vulnerable OpenSSL versions as well. The unfortunate consequence of this vulnerability is that server or client memory may be exposed to the other side of the connection. This has the possibility of exposing private information that the other side of the connection should not have. Within the context of Subversion that means authentication information, details about working copies, data from other clients, private keys used with public key encryption, etc. As a result of the above potential data disclosures, after you have upgraded to non-vulnerable versions of the software, you may want to take additional actions including revoking and reissuing SSL/TLS server and client certificates and resetting user passwords. It is understood that retrieving private keys to certificates may be very difficult, but still possible. Other data may be much easier to retrieve. As such, if these steps are necessary are largely a matter of your risk tolerance. If you are using HTTPS to access your Subversion repositories and do decide to revoke your certificates you should understand that at current Subversion does not support rejecting revoked certificates that would otherwise be trusted. Our HTTP libraries (Neon and Serf) which we depend on for this sort of functionality do not currently provide support for providing an external CRL (Certificate Revocation List), retrieving CRLs from a URL in the certificate, checking certificates via OCSP (Online Certificate Status Protocol) or handling an OCSP response that has been stapled to the TLS handshake. In the meantime, you can disable trusting certificates based on trust in the Certifying Authorities to avoid accepting revoked certificates. To do this you will want to make some configuration changes in your server config file for Subversion (usually at /etc/subversion/servers, ~/.subversion/servers, or %APPDATA%\Subversion\servers, see [3] for more details). Set "ssl-trust-default-ca" to "no" and remove the "ssl-authority-files" setting. By doing this Subversion will prompt for all certificates giving you details on the certificate and a fingerprint. You will then have the opportunity to accept the certificate temporarily or permanently. Server admins should let their users know the fingerprints of the correct certificates. This is similar to the manner in which SSH handles validating they are talking to the server they expect to be. If you have already trusted certificates that are now revoked you will also need to remove them from your authentication store for Subversion. This will be stored under ~/.subversion/auth/svn.ssl.server or %APPDATA%\Subversion\auth\svn.ssl.server. You can delete the entire directory to remove all accepted certificates or just delete specific files within the directory to remove just those certs. The files are simply text files containing some data, you should be able to read them to locate the specific keys you which to remove. We realize that the handling for revoked certificates is far from ideal at this tim
