[PUP-3467] Reject SSLv3 connections in Puppet Created: 2014/10/14
Updated: 2014/10/22 Resolved:
2014/10/21
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
Puppet
Client
None
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Task
Moses Mendoza
Fixed
security
Not Specified
Issue Links:
Blocks
Template:
Story Points:
Sprint:
QA Contact:
customfield_10700 true
2
Platform Client 2014-10-29
Erik Dasher
PUP 3.7.2
Priority:
Assignee:
Votes:
Blocker
Kylo Ginsberg
0
Not Specified
Not Specified
Description
Please evaluate the exposure of puppet open source to the issue highlighted in
http://googleonlinesecurity.blogspot.nl/2014/10/this-poodle-bites-exploiting-ssl-30.html.
If fixes are required, this may result in a coordinated ship with PE.
Comments
Comment by Moses Mendoza [ 2014/10/14 ]
Kylo Ginsberg can you triage? For questions on the RE side, Rob Braden will be RE tech lead for the event.
Comment by Kylo Ginsberg [ 2014/10/14 ]
Josh Cooper assigning to you, since you already commented on the email thread.
Comment by Adrien Thebo [ 2014/10/14 ]
For puppetmaster-passenger this is a moot point, since we started disabling SSLv3 in Puppet 3.7.0:
(https://github.com/puppetlabs/puppet/commit/204b2974bf7d10a41b10532c7565de36e993276a#diff0ae4ea78bb4d8b9f7bc957c03f55a305R21). (Thank $deity we spent all that time screwing around with that
pull request all those months ago.)
I don't think this affects Puppet because executing the attack requires the ability to position sensitive data at a
specific offset in the message as well as being able to tamper with the message order itself. The attack vector
outlined in the paper indicates that malicious Javascript injected via a MITM is one vector, so if there's some
method to coerce an agent/master to send specifically crafted traffic then it might be possible to run the
attack. However I can't think of a way to manipulate an agent HTTP request without having access to the
machine itself.
Comment by Adrien Thebo [ 2014/10/15 ]
I spent more time researching this last night, and this shouldn't have a marked impact on Puppet itself. The
vulnerability in question allows an attacker to decrypt the last byte of an arbitrary block of an encrypted
SSLv3 session on an average of 1 out of 256 requests in ideal conditions. It relies on the fact that when
SSLv3 verifies a message encrypted with CBC, it only validates the last byte of the padding. The value of the
last byte of the padding can be determined by the attacker because the SSL spec requires the last byte of the
padding to be (length_of_padding - 1). The attack works by replacing the padding with a block that the
attacker wants to decrypt. If the message is still valid after this replacement then the attacker can derive the
value of the last byte of the block being attacked.
To make this attack work at all, it requires that the attacker has MITM'd the client in question. If the attacker
can coerce the client to make specially crafted requests then the attack becomes extremely viable and very
dangerous, but this is a fairly high bar. If the attacker cannot coerce the client to make specially crafted
requests then it is dramatically harder to execute the attack. The attack only achieves the effective rate of
1/256 if the message has a full block of padding; I'm not certain if the attack is practical if this condition is
not met.
In the case of Puppet, I can't conceive a way to force either the agent or master to make HTTPS requests at all
without already controlling the system in question. If the attacker can't make requests at all then it precludes
the whole specially crafted request requirement.
Assuming that the attacker has forced the client to use 3DES to use 8 byte blocks, the client message length is
evenly distributed and thus 1 out of every 8 messages has a full block of padding, then an attacker could
decrypt the last byte of a block in the messages around 1 in (8 * 256) 2048 attempts. Assuming that the
attacker only attacks messages with a full block of padding, this means that attack will also interrupt on
average 255 messages because of the incorrect attempt.
In addition, if the attacker has no idea what the structure of the message is, then the attacker will get a random
byte, which is of dubious value. The structure of the messages between the Puppet agent and master is
reasonably structured but is probably not consistent enough for an attacker to determine the significance of
the revealed byte.
Now, if an attacker can coerce a MITM'd system to issue requests where the attacker can control both the
request path and body then the attack gets much more viable. In this case the attacker could probably issue
requests very rapidly and could ensure that the messages have a full block of padding which increases the
probability of success back to 1/256. However this attack is only effective against the content the attacker
can't control. The kind of content that the attacker might go for would be things like basic auth credentials or
session cookies, but Puppet doesn't use either of those. The attacker might be able to retrieve things like agent
facts or the agent report, but if the structure of those serialized structures are not extremely consistent
between requests then we again fall back to the case where the attacker can get a random byte with no context
aside from the offset in the message.
That being said, per Josh's comment we should definitely disable SSLv3. We have zero need for
compatibility with SSLv3 and since we already disable it in puppetmaster-passenger we should be consistent
in disabling it everywhere.
Comment by Josh Cooper [ 2014/10/15 ]
I agree with Adrien Thebo, you have to get the agent to make many requests, while controlling the length of
the message, e.g. HTTP GET.
That said I think we should disable SSLv3 everywhere, e.g. puppet module downloading from the forge, etc.
The only reason I'm aware of to continue supporting SSLv3 is for IE6 browsers that don't understand
TLSv1.0, but that doesn't affect puppet agent/servers.
Comment by Adrien Thebo [ 2014/10/15 ]
As an additional note, Daniele mentioned in #puppet-dev that IE6 actually can support TLS:
[09:37]
daenney finch: True. We disabled SSLv3 everywhere. Turns out
we didn't need it anymore because people upgraded their shit a while
ago
[09:37]
+finch daenney: yeah, the only browser that looks like it
can only use SSLv3 is IE6.
[09:37]
+finch Windows XP with IE7 is fine
[09:37]
+finch and we already disabled it in puppetmaster-passenger
[09:37]
daenney Actually, it can talk TLSv1, it's just disabled by
default
[09:37]
+finch it being SSLv3
[09:38]
+finch In IE6?
[09:38]
daenney Yap
[09:38]
daenney It's somewhere in the advanced security settings
If we have some project that IE6 users might need to use, then we can place the onus on them to change their
security settings to allow TLSv1, or use a more modern browser.
Comment by Josh Cooper [ 2014/10/15 ]
This wiki has good info about which browsers support which ssl protocols:
http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers
Comment by Josh Cooper [ 2014/10/15 ]
So we might have an issue with webrick. It allows SSLv3 and the server will echo information from the
client, enabling the client to control how the data is padded:
$ curl -k
https://arcturus.corp.puppetlabs.net:8140/production/certificate/foo
Not Found: Could not find certificate foo
$ curl -k
https://arcturus.corp.puppetlabs.net:8140/production/certificate/foo1
Not Found: Could not find certificate foo1
$ curl -k
https://arcturus.corp.puppetlabs.net:8140/production/certificate/foo12
Not Found: Could not find certificate foo12
$ curl -k
https://arcturus.corp.puppetlabs.net:8140/production/certificate/foo123
Not Found: Could not find certificate foo123
Update: while the client can affect padding, nothing in the server's HTTP Response is sensitive, i.e. not like
client cookies, so the issue is just that it's using SSLv3, and Adrien Thebo comments below.
Comment by Adrien Thebo [ 2014/10/15 ]
Webrick definitely has issues, but more than just the SSLv3 protocol - we allow single DES:
└> openssl s_client -cipher '!HIGH:!MEDIUM:LOW:!EDH' -ssl3 -connect
localhost:8140
[snip]
SSL-Session:
Protocol
Cipher
[snip]
: SSLv3
: DES-CBC-SHA
└> openssl ciphers DES-CBC-SHA -v
DES-CBC-SHA
SSLv3 Kx=RSA
Mac=SHA1
Au=RSA
Enc=DES(56)
If we're worried about the security of Webrick we should apply our passenger cipher list to webrick as well.
Removing SSLv3 would partially remediate this, but it'll still allow other weak ciphers.
Comment by Josh Cooper [ 2014/10/17 ]
Adrien Thebo and I think we should modify webrick to reject SSLv3 and update the ciphersuite string to
match what we're doing elsewhere. Will pull into our sprint for 3.7.2
Comment by Adrien Thebo [ 2014/10/21 ]
Merged in 501169b.
Comment by Kylo Ginsberg [ 2014/10/21 ]
While this is waiting to clear CI, I'm doing some FR.
Comment by Kylo Ginsberg [ 2014/10/21 ]
Standing up a webrick master with this fix:
An attempt to use sslv3 fails;
> openssl s_client -cipher '!HIGH:!MEDIUM:LOW:!EDH' -ssl3 -connect
localhost:8140
CONNECTED(00000003)
16543:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:/SourceCache/OpenSSL098/OpenSSL098-52/src/ssl/s3_pkt.c:1125:SSL
alert number 40
16543:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:/SourceCache/OpenSSL098/OpenSSL098-52/src/ssl/s3_pkt.c:546:
An attempt to downgrade encryption to LOW fails:
> openssl s_client -connect localhost:8140 -no_tls1
CONNECTED(00000003)
16551:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:/SourceCache/OpenSSL098/OpenSSL098-52/src/ssl/s23_lib.c:182:
Either of the above succeed in 3.7.1. (As a point of comparison wrt sslv2, which we previously dropped,
specifying -ssl2 fails similarly in 3.7.1.)
Comment by Kylo Ginsberg [ 2014/10/21 ]
I'm +1 on this from an FR perspective (assuming it clears CI).
Comment by Rob Reynolds [ 2014/10/21 ]
Passed spec tests at https://jenkins.puppetlabs.com/view/Puppet/view/Stable/job/Puppet-Pipeline-Kickoffstable/74/ - waiting on Acceptance to clear
Comment by Rob Reynolds [ 2014/10/21 ]
Nevermind, acceptance was good.
Acceptanced passed at




https://jenkins.puppetlabs.com/view/Puppet/view/Stable/job/Puppet-Acceptance-Future-Parserstable/82/
https://jenkins.puppetlabs.com/view/Puppet/view/Stable/job/Puppet-Package-Acceptance-stable/106/
https://jenkins.puppetlabs.com/view/Puppet/view/Stable/job/Puppet-Acceptance-Solaris-stable/89/
https://jenkins.puppetlabs.com/view/Puppet/view/Stable/job/Puppet-Acceptance-Windows-stable/97/
Comment by Rob Reynolds [ 2014/10/21 ]
Moving to resolved based on Kylo's comments on FR.
Generated at Tue Feb 09 15:41:56 PST 2016 using JIRA 6.4.12#64027sha1:e3691cc1283c0f3cef6d65d3ea82d47743692b57.