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

Groups > comp.lang.python > #110058 > unrolled thread

(repost) Advisory: HTTP Header Injection in Python urllib

Back to article view | Back to comp.lang.python

Contents

  (repost) Advisory: HTTP Header Injection in Python urllib Paul Rubin <no.email@nospam.invalid> - 2016-06-17 11:49 -0700
    Re: (repost) Advisory: HTTP Header Injection in Python urllib Steven D'Aprano <steve@pearwood.info> - 2016-06-18 11:00 +1000
      Re: (repost) Advisory: HTTP Header Injection in Python urllib Random832 <random832@fastmail.com> - 2016-06-17 23:52 -0400
        Re: (repost) Advisory: HTTP Header Injection in Python urllib Steven D'Aprano <steve@pearwood.info> - 2016-06-19 02:02 +1000
          Re: (repost) Advisory: HTTP Header Injection in Python urllib alister <alister.ware@ntlworld.com> - 2016-06-18 16:38 +0000
          Re: (repost) Advisory: HTTP Header Injection in Python urllib Random832 <random832@fastmail.com> - 2016-06-18 13:28 -0400
            Re: (repost) Advisory: HTTP Header Injection in Python urllib Steven D'Aprano <steve@pearwood.info> - 2016-06-22 01:27 +1000
              Re: (repost) Advisory: HTTP Header Injection in Python urllib Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-06-21 16:09 +0000
          Re: (repost) Advisory: HTTP Header Injection in Python urllib Paul Rubin <no.email@nospam.invalid> - 2016-06-18 13:43 -0700
      Re: (repost) Advisory: HTTP Header Injection in Python urllib Marko Rauhamaa <marko@pacujo.net> - 2016-06-18 11:35 +0300

#110058 — (repost) Advisory: HTTP Header Injection in Python urllib

The blog post below is from a couple days ago:

http://blog.blindspotsecurity.com/2016/06/advisory-http-header-injection-in.html

It reports that it's possible to inject fake http headers into requests
sent by urllib2(python2) and urllib(python3), by getting the library to
retrieve a url concocted to have a newline followed by other headers.  A
malicious site can do this by redirecting from a normal url to a
concocted one.  It gives examples of some exploits possible with this
trick, against Redis and Memcached.

There's a small HN thread here:
   https://news.ycombinator.com/item?id=11921568

Someone there mentions "Python 3.5.0+, 3.4.4+ and 2.7.9+ are not
vulnerable" since there's been a patch, but some Linux distros still use
older versions.

I don't know the situation with python2 urllib or with the request
library.

The blog post criticizes Redis and Memcached for not using any
authentication (since "safe" internal networks are often not safe) and
makes the interesting claim that even services on localhost should use
authentication these days.

[toc] | [next] | [standalone]

#110074

On Sat, 18 Jun 2016 04:49 am, Paul Rubin wrote:

> The blog post below is from a couple days ago:
> 
>
http://blog.blindspotsecurity.com/2016/06/advisory-http-header-injection-in.html

> The blog post criticizes Redis and Memcached for not using any
> authentication (since "safe" internal networks are often not safe) and
> makes the interesting claim that even services on localhost should use
> authentication these days.


That's not quite what they say. They say that the problem is that "trusted
internal networks" are often no safer than the Internet and shouldn't be
trusted. It does also say:

"Even an unauthenticated service listening on localhost is risky these
days."

but fall short of *explicitly* recommending that they should be
authenticated. Although they do *implicitly* do so, by saying that "it
wouldn't be hard" for such services to include a password.

The author doesn't go into details of what sort of attacks against localhost
they're talking about. An unauthenticated service running on localhost
implies, to me, a single-user setup, where presumably the single-user has
admin access to localhost. So I'm not really sure what "risk" they have --
e.g. I'm sure that I could do all sorts of bad things to localhost by
exploiting http services. Or I could just go "sudo rm -rf /" [don't do this
at home]. Or whatever evil thing I had in mind.

But perhaps they mean a scenario where I'm running a service on localhost
and offering it to other users on a local network. In which case it makes
sense: trusted internal networks perhaps shouldn't be trusted.


-- 
Steven

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

#110082

On Fri, Jun 17, 2016, at 21:00, Steven D'Aprano wrote:
> The author doesn't go into details of what sort of attacks against
> localhost they're talking about. An unauthenticated service running on
> localhost implies, to me, a single-user setup, where presumably the
> single-user has admin access to localhost. So I'm not really sure what
> "risk" they have

The issue - especially clearly in this context, which demonstrates a
working exploit for this vulnerability - is cross-site request forgery.
Which doesn't technically require the victim service to be HTTP (I
remember a proof of concept a while back which would trick a browser
into connecting to an IRC server), so long as it can ignore HTTP
headers.

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

#110107

On Sat, 18 Jun 2016 01:52 pm, Random832 wrote:

> On Fri, Jun 17, 2016, at 21:00, Steven D'Aprano wrote:
>> The author doesn't go into details of what sort of attacks against
>> localhost they're talking about. An unauthenticated service running on
>> localhost implies, to me, a single-user setup, where presumably the
>> single-user has admin access to localhost. So I'm not really sure what
>> "risk" they have
> 
> The issue - especially clearly in this context, which demonstrates a
> working exploit for this vulnerability - is cross-site request forgery.
> Which doesn't technically require the victim service to be HTTP (I
> remember a proof of concept a while back which would trick a browser
> into connecting to an IRC server), so long as it can ignore HTTP
> headers.

Er, you may have missed that I'm talking about a single user setup. Are you
suggesting that I can't trust myself not to forge a request that goes to a
hostile site?

It's all well and good to say that the application is vulnerable to X-site
attacks, but how does that relate to a system where I'm the only user?



-- 
Steven

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

#110109

On Sun, 19 Jun 2016 02:02:43 +1000, Steven D'Aprano wrote:

> On Sat, 18 Jun 2016 01:52 pm, Random832 wrote:
> 
>> On Fri, Jun 17, 2016, at 21:00, Steven D'Aprano wrote:
>>> The author doesn't go into details of what sort of attacks against
>>> localhost they're talking about. An unauthenticated service running on
>>> localhost implies, to me, a single-user setup, where presumably the
>>> single-user has admin access to localhost. So I'm not really sure what
>>> "risk" they have
>> 
>> The issue - especially clearly in this context, which demonstrates a
>> working exploit for this vulnerability - is cross-site request forgery.
>> Which doesn't technically require the victim service to be HTTP (I
>> remember a proof of concept a while back which would trick a browser
>> into connecting to an IRC server), so long as it can ignore HTTP
>> headers.
> 
> Er, you may have missed that I'm talking about a single user setup. Are
> you suggesting that I can't trust myself not to forge a request that
> goes to a hostile site?
> 
> It's all well and good to say that the application is vulnerable to
> X-site attacks, but how does that relate to a system where I'm the only
> user?

one possible reason I can think of is if for whatever reason your 
computer is infected by malware that malware could make use of the 
service.



-- 
"The only way for a reporter to look at a politician is down."
-- H.L. Mencken

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

#110110

On Sat, Jun 18, 2016, at 12:02, Steven D'Aprano wrote:
> Er, you may have missed that I'm talking about a single user setup.
> Are you suggesting that I can't trust myself not to forge a request
> that goes to a hostile site?
>
> It's all well and good to say that the application is vulnerable to
> X-site attacks, but how does that relate to a system where I'm the
> only user?

I don't think you understand what cross-site request forgery is, unless
your definition of "single user setup" includes not connecting to the
internet at all. The point is that one site causes the client to send a
request (not desired by the user) to another site. That the client is a
single-user system makes no difference.

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

#110238

On Sun, 19 Jun 2016 03:28 am, Random832 wrote:

> On Sat, Jun 18, 2016, at 12:02, Steven D'Aprano wrote:
>> Er, you may have missed that I'm talking about a single user setup.
>> Are you suggesting that I can't trust myself not to forge a request
>> that goes to a hostile site?
>>
>> It's all well and good to say that the application is vulnerable to
>> X-site attacks, but how does that relate to a system where I'm the
>> only user?
> 
> I don't think you understand what cross-site request forgery is, 

Possibly not.


> unless 
> your definition of "single user setup" includes not connecting to the
> internet at all. The point is that one site causes the client to send a
> request (not desired by the user) to another site. That the client is a
> single-user system makes no difference.

Here's the link again, in case anyone missed it.

http://blog.blindspotsecurity.com/2016/06/advisory-http-header-injection-in.html

I've read it again, and it seems to me that the attack surface is pretty
small. The attacker needs to know that you're running (let's say) memcache,
AND the port you're running it on, AND that you are fetching URLs with
something that allows X-site attacks, AND they have to fool you into
fetching an appropriately crafted URL. From the article:

"In our case, if we could fool an internal Python application into fetching
a URL for us, then we could easily access memcached instances. Consider the
URL: ..."

and then they demonstrate an attack against memcache. Except, the author of
the article knows the port that memcache is on, and he doesn't have to fool
anyone into fetching a hostile URL. He just fetched it himself.

"In our case, if we could fool a person into pointing a gun at their foot
and pulling the trigger, we can blow their foot off. Here is a
proof-of-concept..." (points gun at own foot and pulls trigger)

Absent an actual attack that demonstrates the "fool an internal application"
part, I don't think I'm going to lose too much sleep over this. My house
has many dangerous items, like kitchen knives, power tools and the like. If
somebody could fool me into, say, hitting myself on the head with a hammer,
that would be bad. But until I see a demonstration of how somebody might do
that, I'm not going to keep my hammer under lock and key.

Maybe I'm missing something, but while I acknowledge the general position 
"here's a security flaw", and I accept that it needs to be fixed, I'm not
seeing that this is a sufficiently realistic attack enough to justify
requiring authentication for all internal services.



-- 
Steven

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

#110240

On 2016-06-21, Steven D'Aprano <steve@pearwood.info> wrote:
> "In our case, if we could fool an internal Python application into fetching
> a URL for us, then we could easily access memcached instances. Consider the
> URL: ..."
>
> and then they demonstrate an attack against memcache. Except, the author of
> the article knows the port that memcache is on, and he doesn't have to fool
> anyone into fetching a hostile URL. He just fetched it himself.

memcached, like most services, has a default port. If you know or can
guess that memcached is in use then you probably know the right port
already.

Bear in mind that some very successful attacks rely on quite specific
circumstances but bear fruit anyway if you can manage to do some sort
of scripted attack against a large number of potential victims.

> "In our case, if we could fool a person into pointing a gun at their foot
> and pulling the trigger, we can blow their foot off. Here is a
> proof-of-concept..." (points gun at own foot and pulls trigger)

No, that's not a fair comparison at all.

> Absent an actual attack that demonstrates the "fool an internal application"
> part, I don't think I'm going to lose too much sleep over this. My house
> has many dangerous items, like kitchen knives, power tools and the like. If
> somebody could fool me into, say, hitting myself on the head with a hammer,
> that would be bad.

That's not a valid analogy either. A more appropriate analogy would be
that if someone could get you to hit a specific ordinary-looking nail
then your hammer will bounce off and hit you in the head.

> Maybe I'm missing something, but while I acknowledge the general position 
> "here's a security flaw", and I accept that it needs to be fixed, I'm not
> seeing that this is a sufficiently realistic attack enough to justify
> requiring authentication for all internal services.

I agree, although it is certainly something that people ought to bear
in mind. And it is something that should certainly be fixed in Python.

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

#110112

Steven D'Aprano <steve@pearwood.info> writes:
>> The issue ... is cross-site request forgery.
> Er, you may have missed that I'm talking about a single user setup. Are you
> suggesting that I can't trust myself not to forge a request that goes to a
> hostile site?

I think the idea is you visit some website with malicious script that
accesses your localhost resources from your browser.  So it's not a
matter of trusting yourself.  Rather, it's one of trusting every website
you visit, including the ad servers they transclude, etc.

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

#110092

Steven D'Aprano <steve@pearwood.info>:

> "Even an unauthenticated service listening on localhost is risky these
> days."
>
> but fall short of *explicitly* recommending that they should be
> authenticated. Although they do *implicitly* do so, by saying that "it
> wouldn't be hard" for such services to include a password.

In the local case, one should consider using local domain sockets
(AF_LOCAL), which can reliably identify the peer's credentials
(SO_PASSCRED, SO_PEERCRED).


Marko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web