Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #171462 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  Any idea when CVE-2016-5696 is going to get fixed? "Perry E. Metzger" <perry@piermont.com> - 2016-08-26 17:10 +0200
    Re: Any idea when CVE-2016-5696 is going to get fixed? Mark Fletcher <mark27q1@gmail.com> - 2016-08-26 17:20 +0200
      Re: Any idea when CVE-2016-5696 is going to get fixed? Lisi Reisz <lisi.reisz@gmail.com> - 2016-08-26 18:40 +0200
        Re: Any idea when CVE-2016-5696 is going to get fixed? "Perry E. Metzger" <perry@piermont.com> - 2016-08-26 19:50 +0200
    Re: Any idea when CVE-2016-5696 is going to get fixed? Frederic Marchal <frederic.marchal@wowtechnology.com> - 2016-08-26 21:10 +0200
      Re: Any idea when CVE-2016-5696 is going to get fixed? "Perry E. Metzger" <perry@piermont.com> - 2016-08-27 05:20 +0200
        Re: Any idea when CVE-2016-5696 is going to get fixed? "John T. Haggerty" <jpcookie@gmail.com> - 2016-08-27 05:30 +0200
          Re: Any idea when CVE-2016-5696 is going to get fixed? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-27 17:50 +0200
        Re: Any idea when CVE-2016-5696 is going to get fixed? Frederic Marchal <frederic.marchal@wowtechnology.com> - 2016-08-28 14:40 +0200
          Re: Any idea when CVE-2016-5696 is going to get fixed? "Perry E. Metzger" <perry@piermont.com> - 2016-08-28 21:40 +0200
            Re: Any idea when CVE-2016-5696 is going to get fixed? deloptes <deloptes@gmail.com> - 2016-08-28 23:30 +0200
            Re: Any idea when CVE-2016-5696 is going to get fixed? Tixy <tixy@yxit.co.uk> - 2016-08-29 13:00 +0200
              Re: Any idea when CVE-2016-5696 is going to get fixed? "Perry E. Metzger" <perry@piermont.com> - 2016-08-29 18:20 +0200
                Re: Any idea when CVE-2016-5696 is going to get fixed? Gene Heskett <gheskett@shentel.net> - 2016-08-29 18:40 +0200
                  Re: Any idea when CVE-2016-5696 is going to get fixed? "Thomas Schmitt" <scdbackup@gmx.net> - 2016-08-29 19:40 +0200
                    Re: Any idea when CVE-2016-5696 is going to get fixed? "Perry E. Metzger" <perry@piermont.com> - 2016-08-29 20:30 +0200
                Re: Any idea when CVE-2016-5696 is going to get fixed? deloptes <deloptes@gmail.com> - 2016-08-29 23:50 +0200
                  Re: Any idea when CVE-2016-5696 is going to get fixed? Lisi Reisz <lisi.reisz@gmail.com> - 2016-08-30 00:40 +0200
                    Re: Any idea when CVE-2016-5696 is going to get fixed? Charlie <ariestao1@ipstarmail.com.au> - 2016-08-30 06:50 +0200
          Re: Any idea when CVE-2016-5696 is going to get fixed? "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu> - 2016-08-29 03:30 +0200
            Re: Any idea when CVE-2016-5696 is going to get fixed? Mark Fletcher <mark27q1@gmail.com> - 2016-08-29 05:50 +0200
              Re: Any idea when CVE-2016-5696 is going to get fixed? "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu> - 2016-08-29 07:10 +0200
                Re: Any idea when CVE-2016-5696 is going to get fixed? Salvatore Bonaccorso <carnil@debian.org> - 2016-08-29 07:30 +0200
                  Re: Any idea when CVE-2016-5696 is going to get fixed? "Perry E. Metzger" <perry@piermont.com> - 2016-08-29 18:20 +0200

Page 1 of 2  [1] 2  Next page →

#171462 — Any idea when CVE-2016-5696 is going to get fixed?

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.

Any idea out there when updates to the kernels in question will be
released?

Perry
-- 
Perry E. Metzger		perry@piermont.com

[toc] | [next] | [standalone]

#171463

[Multipart message — attachments visible in raw view] — view raw

On Sat, Aug 27, 2016 at 12:04 AM Perry E. Metzger <perry@piermont.com>
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.
>
> Any idea out there when updates to the kernels in question will be
> released?
>
>
I could have sworn I saw a fix for this sometime last week, as I would only
have become aware of it when the security advisory was published. I built a
new kernel based on 4.7 for my non-debian boxes last weekend, and assumed
the regular updates would take care of Debian. I've long since deleted the
email of course, but I am not sure how I would have even known there was an
issue unless there had been one of the usual mails saying "this issue is
fixed in...". But I agree that is not how the CVE item you linked to makes
it look. Could there be a duplicate, with all the updates on the other one?

Mark

[toc] | [prev] | [next] | [standalone]

#171464

On Friday 26 August 2016 16:13:09 Mark Fletcher wrote:
> On Sat, Aug 27, 2016 at 12:04 AM Perry E. Metzger <perry@piermont.com>
>
> 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.
> >
> > Any idea out there when updates to the kernels in question will be
> > released?
>
> I could have sworn I saw a fix for this sometime last week, as I would only
> have become aware of it when the security advisory was published. I built a
> new kernel based on 4.7 for my non-debian boxes last weekend, and assumed
> the regular updates would take care of Debian. I've long since deleted the
> email of course, but I am not sure how I would have even known there was an
> issue unless there had been one of the usual mails saying "this issue is
> fixed in...". But I agree that is not how the CVE item you linked to makes
> it look. Could there be a duplicate, with all the updates on the other one?

The "fix" seems not to have been dealt with yet, but the list has published a 
workaround at some length in this thread:

https://lists.debian.org/msgid-search/slrnnqp80d.67r.curty@einstein.electron.org

These in particular discuss the "solution":
 https://lists.debian.org/msgid-search/20160811162119.GA19111@e1030
 
https://lists.debian.org/msgid-search/28cd04df-18a6-caa9-d4ff-b4761c3f7dd7@gmail.com

https://lists.debian.org/msgid-search/slrnnqr3sv.3uk.curty@einstein.electron.org

Lisi

[toc] | [prev] | [next] | [standalone]

#171465

On Fri, 26 Aug 2016 17:34:39 +0100 Lisi Reisz <lisi.reisz@gmail.com>
wrote:
> The "fix" seems not to have been dealt with yet, but the list has
> published a workaround at some length in this thread:

Updated kernels have been announced and released by the kernel folks
at this point. (See, for example:

http://seclists.org/oss-sec/2016/q3/294

)

However, no fixed kernels have been released by Debian yet...

Perry
-- 
Perry E. Metzger		perry@piermont.com

[toc] | [prev] | [next] | [standalone]

#171467

[Multipart message — attachments visible in raw view] — view raw

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.

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. 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. That's unlikely to succeed on a massive 
scale if you ask me!

Beside, the attacker can't possibly know what you are downloading and 
how much data has already been downloaded. There is no way he can 
inject anything useful into the downloaded data. You would end up with a 
corrupted file in the worst case. A worm can't propagate that way.

Frederic

[toc] | [prev] | [next] | [standalone]

#171473

On Fri, 26 Aug 2016 21:06:15 +0200 Frederic Marchal
<frederic.marchal@wowtechnology.com> 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.

At the security conference where the attack was presented, as a show
of force, the presenters demonstrated that they could hijack arbitrary
http: connections from several US newspapers and inject whatever
traffic they like using this.

Indeed, as a bit of comedy, they used this to do their presentation!
They had a web browser to go to a newspaper's site and injected their
slides for the talk into the newspaper's web page return and
presented their talk that way! You will be able watch the video
yourself online when Usenix posts it soon.

This means, for example, that you can inject javascript into the pages
coming off of (say) a newspaper's unencrypted web site, and this
lets you do untold mischief. With this attack, you could, for
example, have weaponized the attacks described against iOS yesterday
(resulting in an iOS emergency update) without getting a user to
click on a malicious page, simply by injecting malicious javascript
into a real page of a site hosted on a debian server. (I link to the
report of that particular incident below, to give one a taste of the
modern threat environment.)

This is a horribly bad attack. Thinking this is nothing but denial of
service could not be more incorrect.

> 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.

> 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
more where someone downloaded some static HTML and closed the TCP
connection until the next page was downloaded when they clicked
again. It hasn't been like that in a very long time.

> That's unlikely to succeed on a massive scale if you ask me!

You clearly didn't watch the presentation of people
doing this attack successfully against real web pages while people
were using them. This isn't theoretical. You should also remember
that we're no longer in the "but who would do *that*" world. If you
want to understand the threat model people live under now, read

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

> Beside, the attacker can't possibly know what you are downloading
> and how much data has already been downloaded. There is no way he
> can inject anything useful into the downloaded data.

Watch the real world demos. As I said, the videos are online. What
you say is wrong.

Perry
-- 
Perry E. Metzger		perry@piermont.com

[toc] | [prev] | [next] | [standalone]

#171475

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 26, 2016 at 9:11 PM, Perry E. Metzger <perry@piermont.com>
wrote:

> On Fri, 26 Aug 2016 21:06:15 +0200 Frederic Marchal
> <frederic.marchal@wowtechnology.com> 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.
>
> At the security conference where the attack was presented, as a show
> of force, the presenters demonstrated that they could hijack arbitrary
> http: connections from several US newspapers and inject whatever
> traffic they like using this.
>
> Indeed, as a bit of comedy, they used this to do their presentation!
> They had a web browser to go to a newspaper's site and injected their
> slides for the talk into the newspaper's web page return and
> presented their talk that way! You will be able watch the video
> yourself online when Usenix posts it soon.
>
> This means, for example, that you can inject javascript into the pages
> coming off of (say) a newspaper's unencrypted web site, and this
> lets you do untold mischief. With this attack, you could, for
> example, have weaponized the attacks described against iOS yesterday
> (resulting in an iOS emergency update) without getting a user to
> click on a malicious page, simply by injecting malicious javascript
> into a real page of a site hosted on a debian server. (I link to the
> report of that particular incident below, to give one a taste of the
> modern threat environment.)
>
> This is a horribly bad attack. Thinking this is nothing but denial of
> service could not be more incorrect.
>
> > 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.
>
>
Having read several texts on internet security, I'd be interested in what
you are referring to. You mean compromise the physical machine they are on
to view their browser history? Break into their home? Packet sniffing?



> > 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
> more where someone downloaded some static HTML and closed the TCP
> connection until the next page was downloaded when they clicked
> again. It hasn't been like that in a very long time.
>
>
So you are referring to the "netstat" output from the system itself? So
physically redraw the page they are on even if they haven't refreshed the
page?


> > That's unlikely to succeed on a massive scale if you ask me!
>
> You clearly didn't watch the presentation of people
> doing this attack successfully against real web pages while people
> were using them. This isn't theoretical. You should also remember
> that we're no longer in the "but who would do *that*" world. If you
> want to understand the threat model people live under now, read
>
> https://citizenlab.org/2016/08/million-dollar-dissident-
> iphone-zero-day-nso-group-uae/
>
>
Seems to be the NSA from reading about that.


> > Beside, the attacker can't possibly know what you are downloading
> > and how much data has already been downloaded. There is no way he
> > can inject anything useful into the downloaded data.
>
> Watch the real world demos. As I said, the videos are online. What
> you say is wrong.
>
> Perry
> --
> Perry E. Metzger                perry@piermont.com
>
>

I'd love to see that as well. I don't keep up with many conferences that I
don't personally attend. Is there a cost?

-- 
"The death of one man is a tragedy, the death of 10 million is a statistic"
-- Joseph Stalin

"Omnia mutantur, nihil interit"
(Translation:
Everything changes, nothing is lost.)
-- Ovid, _Metamorphoses_

[toc] | [prev] | [next] | [standalone]

#171482

"John T. Haggerty" <jpcookie@gmail.com> writes:

> On Fri, Aug 26, 2016 at 9:11 PM, Perry E. Metzger <perry@piermont.com>
> wrote:
>
>    On Fri, 26 Aug 2016 21:06:15 +0200 Frederic Marchal
>    <frederic.marchal@wowtechnology.com> wrote:
>
>     > 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
>     more where someone downloaded some static HTML and closed the TCP
>     connection until the next page was downloaded when they clicked
>     again. It hasn't been like that in a very long time.
>
> So you are referring to the "netstat" output from the system itself?
> So physically redraw the page they are on even if they haven't
> refreshed the page?

I'm not sure how netstat is relevant here....  but think of protocols
like AJAX where, indeed, content on a web page can be updated without
any user activity.  Do you have a facebook account?  I frequently have a
browser open to it for days at a time while it updates my feed (in
fairness, that's https: not http:, but the point about long-lived
connections remains valid).

[toc] | [prev] | [next] | [standalone]

#171489

[Multipart message — attachments visible in raw view] — view raw

On Friday 26 August 2016 23:11:23 Perry E. Metzger wrote:
> On Fri, 26 Aug 2016 21:06:15 +0200 Frederic Marchal
> 
> <frederic.marchal@wowtechnology.com> 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

[toc] | [prev] | [next] | [standalone]

#171491

On Sun, 28 Aug 2016 14:35:01 +0200 Frederic Marchal
<frederic.marchal@wowtechnology.com> 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.
> 
> 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).

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.

> 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.

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
-- 
Perry E. Metzger		perry@piermont.com

[toc] | [prev] | [next] | [standalone]

#171495

Perry E. Metzger wrote:

> The hole needs to be fixed.

AMEN

[toc] | [prev] | [next] | [standalone]

#171512

On Sun, 2016-08-28 at 15:36 -0400, Perry E. Metzger wrote:
> On Sun, 28 Aug 2016 14:35:01 +0200 Frederic Marchal
[...]
> > 
> > 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,

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

[toc] | [prev] | [next] | [standalone]

#171530

On Mon, 29 Aug 2016 11:55:03 +0100 Tixy <tixy@yxit.co.uk> wrote:
> On Sun, 2016-08-28 at 15:36 -0400, Perry E. Metzger wrote:
> > On Sun, 28 Aug 2016 14:35:01 +0200 Frederic Marchal  
> [...]
> > > 
> > > 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,  
> 
> 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
-- 
Perry E. Metzger		perry@piermont.com

[toc] | [prev] | [next] | [standalone]

#171531

On Monday 29 August 2016 12:11:27 Perry E. Metzger wrote:

> On Mon, 29 Aug 2016 11:55:03 +0100 Tixy <tixy@yxit.co.uk> wrote:
> > On Sun, 2016-08-28 at 15:36 -0400, Perry E. Metzger wrote:
> > > On Sun, 28 Aug 2016 14:35:01 +0200 Frederic Marchal
> >
> > [...]
> >
> > > > 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,
> >
> > 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

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>

[toc] | [prev] | [next] | [standalone]

#171532

Hi,

Gene Heskett wrote:
> 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?

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

[toc] | [prev] | [next] | [standalone]

#171533

On Mon, 29 Aug 2016 19:30:11 +0200 "Thomas Schmitt"
<scdbackup@gmx.net> wrote:
> Hi,
> 
> Gene Heskett wrote:
> > 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?  
> 
> 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.

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
-- 
Perry E. Metzger		perry@piermont.com

[toc] | [prev] | [next] | [standalone]

#171539

Perry E. Metzger wrote:

> 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.

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

[toc] | [prev] | [next] | [standalone]

#171540

On Monday 29 August 2016 22:44:52 deloptes wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#171542

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

> On Monday 29 August 2016 22:44:52 deloptes wrote:
> > 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.

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

[toc] | [prev] | [next] | [standalone]

#171498

On Sun, 28 Aug 2016 14:35:01 +0200
Frederic Marchal <frederic.marchal@wowtechnology.com> wrote:

> 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.

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web