Subject: Re: Any idea when CVE-2016-5696 is going to get fixed?

From: Frederic Marchal <[email-masked]>
Date: Sun, 28 Aug 2016 14:35:01 +0200

On Friday 26 August 2016 23:11:23 Perry E. Metzger wrote:
> On Fri, 26 Aug 2016 21:06:15 +0200 Frederic Marchal
> 
> <[email-masked]> wrote:
> > On Friday 26 August 2016 11:04:04 Perry E. Metzger wrote:
> > > According to:
> > > 
> > > https://security-tracker.debian.org/tracker/CVE-2016-5696
> > > 
> > > Wheezy and Jessie are still vulnerable. The attack in question is
> > > kind of bad (it allows blind injection of arbitrary data into
> > > things like http downloads) and has been known for a few weeks
> > > now to the general public.
> > 
> > I don't think the issue is that bad.
> > 
> > It allows an attacker to find out if you are connected to a
> > particular web site and makes it easier to interrupt the transfer
> > by sending a RST or SYN packet or inject junk data to corrupt the
> > flow. It's simple denial of service.
> 
> You are completely wrong. This attack allows you to inject
> *meaningful* things into the data flow. It isn't denial of service,
> it is one of the most flexible data injection attacks in years.

You are referring to this paper by Yue Cao and al:

http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf

The paper explains how a patch described in RFC5961 makes it even 
easier to guess the correct TCP sequence number. The paper states that 
it is trivial to inject legitimate looking packets into a long-lived, 
unencrypted, TCP connection with few packets exchanged between the 
client and server.

The requirements are:

* TCP connection,
* long-lived,
* unencrypted,
* long silences.

I'll add that the protocol must allow the server to initiate data sending with 
only one packet (such as news pushed from the server to the client). Any 
protocol relying on an exchange is ruled out as the attacker won't see the 
victim's response.

The authors found www.usatoday.com meets the requirements.

Even if the requirements are met, the attack fails if the client is protected 
by a stateful firewall (either on a NAT router, modem or computer). The 
attacker needs a direct connection to an open port to probe the target 
system.

If the attack is made against the server: I expect any decent server 
accepting data from a client to use https (I may be presuming too much 
here :-) ).

The attack is also useless if the attacker can't spoof the source IP 
address. Routers in corporate environments usually block this by design or 
due to VLAN. For that reason, the attack can't come from the same LAN to 
bypass the border firewall. This rules out an unhappy coworker, infected 
computer or a student with too much time on his hands.

I bet the authors demonstrated the exploit in a very hacker friendly 
environment by disabling the target computer firewall and using a switch 
to connect the attacker and the victim on the same LAN.

Now, I wonder if many sites or protocols do meet the requirements.

Except for the above requirements, I can't see many cases where 
legitimate packets injection is possible without visible side effects giving 
the attack away.

It is not as simple as randomly injecting <script>alert("hello")</script> into 
any given open connection and expect it to land nicely in an HTML stream 
without breaking something visible to the end user (assuming the client is 
downloading html and not css, js, png, json,…). Yet, it is what attackers 
have to deal with on most sites.

> > But to achieve that, you must be downloading something from a web
> > site the attacker is actually targeting. The attacker must know you
> > are doing so or find out by sheer luck.
> 
> "Sheer luck" isn't hard at all. There are a half dozen good ways
> understood to people in the field where you can figure out what
> sites someone is looking at regularly if you are targeting them
> without needing to listen in on their connection directly.

Knowing someone is connected to a particular web site is only the first and 
easier step (just watch when someone post a message for instance).

The attacker must then find (without looking at the actual connection) the 
following data:

* the actual server IP address when multiple servers serves the web site 
(load balancing),
* the client IP address (not as easy as it sound except when targeting an 
individual for which data have been collected by other channels);
* the TCP source port;
* a valid TCP sequence number.

In the best case, it takes some time (around one minute according to the 
paper). The connection must last that long.

AJAX is not a candidate as AJAX goes like this:

Client connects to server.
Client to server: is there something new?
Server to client: no.
Close connection.
Wait some time...
Client connects to server.
Client to server: is there something new?
Server to client: yes, display X.
Close connection.

Due to the keep-alive timeout, sparse AJAX requests are all independent 
connections. All using a different TCP sequence number and source port. 
They rarely last long enough to inject anything.

Ssh lasts long enough with long silences the attacker can exploit to inject 
packets without risking conflicts with regular client/server packets. But it is 
encrypted. So it is impossible to inject any legitimate data.

Websocket may be a better candidate. Maybe a site build with meteor.js or 
webtoolkit would offer some opportunities provided it doesn't use https.

Plain unencrypted IMAP might work if the attacker can guess a lot of data 
about the actual mailbox content. Failure to get the correct data would 
result in the mail client displaying inconsistent data. TLS renders the 
attack useless except as a bothersome denial of service (please forgive 
the understatement if it ever happened to you :-) ).

> > The download must be long
> > enough (more than one minute) for the attacker to discover the set
> > of parameters that will make the attack successful.
> 
> You've forgotten how the modern web works. People have http:
> connections live for very long periods of time, with dynamic content
> flittering back and forth over the channel. It isn't like 1996 any

---

From: "Neal P. Murphy" <[email-masked]>
Date: Sun, 28 Aug 2016 17:57:10 -0400

On Sun, 28 Aug 2016 14:35:01 +0200

> computer or a student with too much time on his hands.

This is the first and foremost requirement. If the packets' source address cannot be spoofed, the attack cannot be attempted.

I'm less concerned with how many sites/protocols are vulnerable than I am with how many ISPs allow spoofed packets out of their networks. It should be trivial for any ISP to drop packets that, given the source address, could not have originated within its network.

In fact, I'd go so far as to say that no ISP should be allowed to connect to the internet unless solid anti-spoofing measures are in place.

The CVE may be primarily of academic interest, but it is still a vulnerability that must be addressed. And the Debian crew will address it soon enough.

---

From: Mark Fletcher <[email-masked]>
Date: Mon, 29 Aug 2016 03:43:15 +0000

On Mon, 29 Aug 2016 at 10:21, Neal P. Murphy <[email-masked]>
wrote:

> This is the first and foremost requirement. If the packets' source address
> cannot be spoofed, the attack cannot be attempted.
>
> I'm less concerned with how many sites/protocols are vulnerable than I am
> with how many ISPs allow spoofed packets out of their networks. It should
> be trivial for any ISP to drop packets that, given the source address,
> could not have originated within its network.
>
> In fact, I'd go so far as to say that no ISP should be allowed to connect
> to the internet unless solid anti-spoofing measures are in place.
>
> The CVE may be primarily of academic interest, but it is still a
> vulnerability that must be addressed. And the Debian crew will address it
> soon enough.
>
> Version 4.7 of the kernel contains a fix, which only required changes to
one source file, so I assume it's a question of back porting that fix into
the Jessie version of the kernel. I might take a look at trying that and
submit a patch if I can get it to work. (Now watch me trip over a dozen
issues I didn't think of when I try this)

Mark

---

From: "Neal P. Murphy" <[email-masked]>
Date: Mon, 29 Aug 2016 01:08:45 -0400

On Mon, 29 Aug 2016 03:43:15 +0000

> issues I didn't think of when I try this)

Greg K-H backported the fix(es) to 3.14.76. And a fix to the fix in 3.14.77. And Ben H. has the patch in 3.16.37, which is likely closer to what you need). The patches involve increasing the limit to 1000 ± some random factor, and per-socket rate limiting. It shouldn't be *too* difficult to backport that patch to Debian's kernel.

---

From: Salvatore Bonaccorso <[email-masked]>
Date: Mon, 29 Aug 2016 07:25:42 +0200

Hi,

On Mon, Aug 29, 2016 at 01:08:45AM -0400, Neal P. Murphy wrote:
> Greg K-H backported the fix(es) to 3.14.76. And a fix to the fix in
> 3.14.77. And Ben H. has the patch in 3.16.37, which is likely closer
> to what you need). The patches involve increasing the limit to 1000
> ± some random factor, and per-socket rate limiting. It shouldn't be
> *too* difficult to backport that patch to Debian's kernel.

The issue is already been worked on by Ben for all versions in sid,
jessie (and wheezy lts):

sid:
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=sid&id=7184d7bfd94443b6403d71da639ec390224af594
(but then later just used as with 4.7.2 uploaded yesterday).

jessie:
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=jessie-security&id=1bd5c3370523e5846019361b33a97c754db76f8d

wheezy:
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=wheezy-security&id=f383788fb866fc61daf26836bccd92ebf7a6f02f

HTH,

Regards,
Salvatore

---

From: "Perry E. Metzger" <[email-masked]>
Date: Mon, 29 Aug 2016 12:13:25 -0400

> https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=wheezy-security&id=f383788fb866fc61daf26836bccd92ebf7a6f02f

Very cool. Any idea when the actual release by the security people
might be?

Perry
-- 
Perry E. Metzger		[email-masked]

---

From: "Perry E. Metzger" <[email-masked]>
Date: Sun, 28 Aug 2016 15:36:24 -0400

On Sun, 28 Aug 2016 14:35:01 +0200 Frederic Marchal
<[email-masked]> wrote:
> The requirements are:
> 
> * TCP connection,
> * long-lived,
> * unencrypted,
> * long silences.
> 
> I'll add that the protocol must allow the server to initiate data
> sending with only one packet (such as news pushed from the server
> to the client). Any protocol relying on an exchange is ruled out as
> the attacker won't see the victim's response.
> 
> Even if the requirements are met, the attack fails if the client is
> protected by a stateful firewall (either on a NAT router, modem or
> computer).

So essentially no smartphones are protected, and only a fraction of
the world's end users.

> The attacker needs a direct connection to an open port
> to probe the target system.

Yup. Not a big deal if you're directly targeting someone. It isn't
like there's any shortage of situations where this comes up.

Before the Snowden revelations, I used to presume that people claiming
that a hole like this wasn't critical to patch were simply not
thinking clearly. Now I wonder every time if they're shills for
intelligence agencies.

> The attack is also useless if the attacker can't spoof the source
> IP address.

Which means most of the world's machines directly connected to the
internet, see the stats from CAIDA and others on how much ingress
filtering is happening (not much).

> Routers in corporate environments usually block this by
> design or due to VLAN.

Yes, but you need to be in a position to spoof from somewhere, not in
a position to spoof from everywhere. Your mentioning of corporate
networks that control spoofing is uninteresting, since you can spoof
from most direct connections to the internet.

Again, as it stands right now, loads of users of random newspaper and
other web sites are vulnerable to injection attacks because of
this.

There are people working under horrid conditions for the freedom of
their countries in all sorts of places who are routinely targeted by
the state agencies of dictatorships and other miscreants who would
like to inject malware onto their phones and personal computers. This
is not a theoretical problem.

Again, read an article like:

https://citizenlab.org/2016/08/million-dollar-dissident-iphone-zero-day-nso-group-uae/

to understand what the modern security situation is like.

You are arguing that it is utterly unimportant that injection attacks
against such people are fairly straightforward if they go to totally
legitimate web sites hosted on servers running Debian.

Real people die this way nowadays, or end up being tortured
indefinitely in third world hellholes because their equipment gets
compromised by FinFisher, the Hacking Group, and other suppliers of
malware to third world dictatorships.

This sort of thing cannot be ignored by an operating system
supplier. One has a social responsibility to fix holes like this.

> I bet the authors demonstrated the exploit in a very hacker
> friendly environment by disabling the target computer firewall and
> using a switch to connect the attacker and the victim on the same
> LAN.

No, the demonstrated it on the ordinary WiFi at a conference without
modification.

> legitimate packets injection is possible without visible side
> effects giving the attack away.

The "above requirements" are met by tens of thousands of totally
legitimate web sites that one might choose to connect to that are
running Linux kernels of appropriate vintage.

Again, in spite of a public demonstration of this, you still insist it
isn't feasible? And again, leaving such holes unpatched puts
people at risk -- and at an utterly unnecessary risk.

You claim this isn't easily feasible, but it has been demoed. It is
known possible.

The hole needs to be fixed.

Perry

---

From: Tixy <[email-masked]>
Date: Mon, 29 Aug 2016 11:55:03 +0100

> On Sun, 28 Aug 2016 14:35:01 +0200 Frederic Marchal
[...]
> So essentially no smartphones are protected,

In my experience, devices on mobile phone networks don't have public IP
addresses, so they must be behind some kind of NAT routing.

-- 
Tixy

---

From: "Perry E. Metzger" <[email-masked]>
Date: Mon, 29 Aug 2016 12:11:27 -0400

On Mon, 29 Aug 2016 11:55:03 +0100 Tixy <[email-masked]> wrote:
> > > Even if the requirements are met, the attack fails if the
> > > client is protected by a stateful firewall (either on a NAT
> > > router, modem or computer).  
> > 
> In my experience, devices on mobile phone networks don't have
> public IP addresses,

Not true, and certainly not universally true. Indeed, more and more
now have v6 addresses as well as v4. Regardless, it makes no
difference as you can still attack the devices in spite of the NAT.

I don't get why everyone wants to argue that a problem that is known
to be bad and is fixed in the kernel versions released by the kernel
maintainers should be ignored.

Perry

---

From: deloptes <[email-masked]>
Date: Mon, 29 Aug 2016 23:44:52 +0200

> maintainers should be ignored.

I'm asking myself the same, but I'm not psychotherapist to be able to
answer.
For instance a fact: "the probability of nuclear war now is higher than 25y
ago".
Mostly got an answer: "You are paranoid!"

or when I say "We must protect our data in terms of encryption, good
firewall etc", my wife asks "Why do you think someone is interested in your
activities?". My answer was "I don't know and this is the point."

Crazy but fact. IMHO people try to convince themself it will never happen
(to them). I would like to know why and how one could deal with such line
of argumentation.

regards

---

From: Lisi Reisz <[email-masked]>
Date: Mon, 29 Aug 2016 23:39:01 +0100

> (to them). I would like to know why and how one could deal with such line

You can't.  I live with it!  I now just say: please, please, please, if you 
must publish your own personal data (name, date of birth, address, bank 
account details etc. etc.) far and wide, would you not publish mine?

A recent study showed that pessimists live 3 to 4 years longer than optimists.  
I'm afraid that I can't for now reference it.  That is clearly because of 
their healthy paranoia!

Lisi

---

From: Charlie <[email-masked]>
Date: Tue, 30 Aug 2016 14:47:53 +1000

On Mon, 29 Aug 2016 23:39:01 +0100 Lisi Reisz sent:

> > Crazy but fact. IMHO people try to convince themself it will never
> > happen (to them). I would like to know why and how one could deal
> > with such line of argumentation.  
> 
> You can't.  I live with it!  I now just say: please, please, please,
> if you must publish your own personal data (name, date of birth,
> address, bank account details etc. etc.) far and wide, would you not
> publish mine?
> 
> A recent study showed that pessimists live 3 to 4 years longer than
> optimists. I'm afraid that I can't for now reference it.  That is
> clearly because of their healthy paranoia!
> 
> Lisi
> 

	After contemplation, my reply is:

http://www.huffingtonpost.com.au/entry/pessimists-live-longer-lives-study_n_2781598

-- 
	Registered Linux User:- 329524
	***********************************************

	However mean your life is, meet it and live it; do not shun it
	and call it hard names. It is not so bad as you are. It looks
	poorest when you are the richest. -Henry David Thoreau

	***********************************************

	Debian GNU/Linux - Magic indeed.

	-----------------------------------------------------

---

From: Gene Heskett <[email-masked]>
Date: Mon, 29 Aug 2016 12:34:57 -0400

> maintainers should be ignored.

I concur.  Normally security things are pushed right on thru particularly 
when they are a one file changed in the whole kernel source tree.  Why 
not this time?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

---

From: "Thomas Schmitt" <[email-masked]>
Date: Mon, 29 Aug 2016 19:30:11 +0200

Hi,

Gene Heskett wrote:
> Normally security things are pushed right on thru particularly 

I guess because it is easy to work around

  https://access.redhat.com/security/vulnerabilities/challengeack

and the maintainers don't want to shoot their foot immediately again
by a hasty bugfix release.

Have a nice day :)

Thomas

---

From: "Perry E. Metzger" <[email-masked]>
Date: Mon, 29 Aug 2016 14:28:13 -0400

On Mon, 29 Aug 2016 19:30:11 +0200 "Thomas Schmitt"
<[email-masked]> wrote:
> > when they are a one file changed in the whole kernel source
> > tree.  Why not this time?  
> 

The official bug fix is already done in the 4.7 kernel and has been
back ported to all the kernels of interest. Apparently it is in the
works for the Debian tree already, though no one has said when the
patches will be released.

As for workarounds, they do no good for the overwhelming majority of
users since they are unaware that they need to push out workarounds.
Users rely on the security update mechanism to get their security
updates. Most organizations aren't even equipped to follow the
torrent of security alerts happening at any given time on an
independent basis.

Perry

---

From: deloptes <[email-masked]>
Date: Sun, 28 Aug 2016 23:10:25 +0200

> The hole needs to be fixed.

AMEN