
OpenSSL SSL3_AL_WARNING undefined alert remote DoS - attilagyorffy
http://seclists.org/oss-sec/2016/q4/224
======
user5994461
> An attacker could repeat the undefined plaintext warning packets of
> "SSL3_AL_WARNING" during the handshake, which will easily make to consume
> 100% CPU on the server.

> It is an implementation problem in OpenSSL that OpenSSL would ignore
> undefined warning, and continue dealing with the remaining data(if exist).
> So the attacker could pack multiple alerts inside a single record and send a
> large number of there large records. Then the server will be fallen in a
> meaningless cycle, and not available to any others.

SSL3 is vulnerable and should be banned in the webserver's configuration. It
stopped being supported by major browsers years ago.

The article doesn't say if webservers are vulnerable when they block SSL3
entirely. If so, it's the hell of a critical vulnerability! Otherwise,
[http://disablessl3.com/](http://disablessl3.com/)

~~~
tveita
There is a fair bit in common between the different versions of SSL/TLS, and
functions and constants in OpenSSL tend to get get named with the version of
the protocol they were introduced in.

So "SSL3_AL_WARNING" isn't necessarily exclusively used in SSLv3, if the
format wasn't changed in TLS.

~~~
yuhong
This is why I consider merging SSLv2 and SSLv3 into the term "SSL" a misnomer.
The two are really completely different protocols.

------
kfreds
"All versions (SSL3.0, TLS1.0, TLS1.1, TLS1.2) are affected." according to
[http://security.360.cn/cve/CVE-2016-8610/](http://security.360.cn/cve/CVE-2016-8610/)

It would be helpful if the researchers clarified how potent this DoS attack
vector is. Is sending "a large number of these large records" more efficient
at denying availability than a naive flood using e.g. SYNs or UDP?

~~~
Terribledactyl
That's a per-site/victim question, how big is your pipe, how big is your CPU,
what kind of networking devices do you offload traffic on?

------
duskwuff
This seems like a pretty... weak vulnerability.

Sure -- you can send an SSL server a bunch of junk data, and it'll try to
process that data. But from what I gather, it's not as though it takes an
unusually long time for it to process these warnings either. Any attacker with
the resources to perform this attack could probably just as easily saturate
the host's network connection without involving SSL at all.

~~~
dogma1138
Not necessarily, DoS is all about asymmetry if it's 1:1 then yeah but if this
only requires a handful of packets to cause the same resource exhaustion as
1000s or 10000s of normal SSL sessions then this is an issue.

You can't bring a site down from your phone normally if there is a CPU eating
bug on the other hand you can.

~~~
duskwuff
Right, of course. I just don't see any reason that there would be an
especially high "multiplier" on this vulnerability. A spurious SSL warning
doesn't require the server to do anything particularly expensive; it just
requires it to look at the ID, realize it's something weird that it doesn't
recognize, and move on.

------
attilagyorffy
there's currently no post on openssl.org but i expect them to publish one
soon. Also, now with all the OpenSSL sh*tstorm this year, I really wonder if
LibreSSL is vulnerable to this security problem...

~~~
adrianN
LibreSSL has removed SSL3, so I'd guess it doesn't do "SSL3_AL_WARNING"

~~~
cm3
And Firefox 52 is proposed to default to TLS 1.3 for safety and performance
reasons:
[https://groups.google.com/forum/#!topic/mozilla.dev.platform...](https://groups.google.com/forum/#!topic/mozilla.dev.platform/sfeqeMkyxCI)

I wish it was still possible to override these per profile. Last time I tried,
the knobs were gone and had no effect whatsoever to enable safer defaults. I
used to be able to force a minimum TLS version and enable only select few
ciphers.

~~~
johnp_
Still possible:

security.tls.version.min security.tls.version.max

security.ssl3.<cipher_suite>

~~~
cm3
Thanks, you're right, found and disabled all but two specs and tuned minimum
to 3 which is TLS1.2. Will put those in the locked config file, so that
they're read-only at runtime.

------
cyg07
so far nginx is the only server which is affected by this issue, but the
latest version wasnt affected.

