Severe security vulnerability?: ajax shell in traceback
Mats
I just installed Pylons and found the ability to execute python
commands within the traceback pretty cool.
Unfortunately I'm concerned that this could be a major security
vulnerability. I was expecting that there might be some restriction on
which machines can access the server, e.g. only to accept HTTP
requests from localhost. I asked a friend to check from his computer
and this was not the case: I was giving shell access to my machine to
the entire web!
It seems that some bright hacker or hacker network could look for
computers with port 5000 open and attempt to make an HTTP request for
a non-existent page, and if it's running Pylons then the script could
automatically insert very nasty code into the traceback from the 404-
like error message...
( Yes, the development.ini file says that we should enable the
debug=False option for production, but in my humble opinion 1) that
message seems rather hidden (as opposed to an explicit warning yes/no
prompt the first time one runs "paster --serve development.ini"), and
2) it seems to imply that running with debug=True as the default state
is fine when you're new to Pylons and just wish to test this out of
the box. )
Please, could someone confirm or allay my confusion as to why this is
not a major security vulnerability and not off by default?, and
perhaps suggest a way to keep this feature on but restrict access?
At the very least, I would humbly recommend a command-line prompt when
starting up for the first time...
Thank you,
Mats
Christoph Haas
On Sonntag, 6. Juli 2008, Mats wrote:
> I just installed Pylons and found the ability to execute python
> commands within the traceback pretty cool.
>
> Unfortunately I'm concerned that this could be a major security
> vulnerability. I was expecting that there might be some restriction on
> which machines can access the server, e.g. only to accept HTTP
> requests from localhost. I asked a friend to check from his computer
> and this was not the case: I was giving shell access to my machine to
> the entire web!
>
> It seems that some bright hacker or hacker network could look for
> computers with port 5000 open and attempt to make an HTTP request for
> a non-existent page, and if it's running Pylons then the script could
> automatically insert very nasty code into the traceback from the 404-
> like error message...
>
> ( Yes, the development.ini file says that we should enable the
> debug=False option for production, but in my humble opinion 1) that
> message seems rather hidden (as opposed to an explicit warning yes/no
> prompt the first time one runs "paster --serve development.ini"), and
> 2) it seems to imply that running with debug=True as the default state
> is fine when you're new to Pylons and just wish to test this out of
> the box. )
The warning about the debug mode isn't that hard to find. The senior chief
deployment officer is supposed to customize the INI file anyway because
that's what controls the behavior of the deployed application. You can't
really blame the developer of the software if their users don't read the
documentation.
Pylons is lead developed in the USA but I hope that doesn't meant that we
others need all these security stickers like telling that microwaves
aren't suited well for drying cats and that you should remove the
sunscreen from your car before driving.
The warning is there. And the paste_deploy_config.ini_tmpl (the template
that is used to create INI files when you deploy the application) has set
debug to False. So almost everybody should be safe. And the others deserve
to get hacked. :)
Cheers
Christoph
--
When you do things right people won't be sure you've done anything at all.
Mats
On Jul 6, 4:50 am, Christoph Haas <em...@christoph-haas.de> wrote:
> Hi, Mats...
> The warning about the debug mode isn't that hard to find. The senior chief
> deployment officer is supposed to customize the INI file anyway because
> that's what controls the behavior of the deployed application. You can't
> really blame the developer of the software if their users don't read the
> documentation.
entitled "Installing Pylons" and "Getting Started", which nowhere
state that modifying the development.ini file is necessary (or even
encourage it) before the point that the user was encouraged to run the
startup script.
> Pylons is lead developed in the USA but I hope that doesn't meant that we
> others need all these security stickers like telling that microwaves
> aren't suited well for drying cats and that you should remove the
> sunscreen from your car before driving.
> The warning is there. And the paste_deploy_config.ini_tmpl (the template
> that is used to create INI files when you deploy the application) has set
> debug to False. So almost everybody should be safe. And the others deserve
> to get hacked. :)
the fine Pylons community, was addressed by sarcasm (paragraph 2) and
"that I deserve to get hacked" (paragraph 3) as a response.
After further pondering, I feel this is a valid concern (not addressed
in docs or startup script), and I would kindly reiterate to the
community that this seems in my humble opinion like a security
vulnerability, and some simple ways to address this might be to 1)
inform the user while running the startup script, or to 2) restrict
the session to localhost-only with a warning of how to disable this in
a startup script message (with a warning to disable debug), or to 3)
disable this feature by default but mention how to enable it in the
documentation (which would be unfortunate because it is a cool
feature), as well as to modify the warning message in development.ini
(should the user happen to see it) to change the words "a production
environment" to "any environment not in a sandbox".
If people disagree with my sentiments (that this was addressed before
docs:GettingStarted-section3, or that looking at the development.ini
file should be obvious for a newbie, or that this would be hard to
exploit), my intent was to merely state my concern and a few
suggestions, not argue it. Hope it helps.
Best wishes,
Mats
> Cheers
> Christoph
> --
> When you do things right people won't be sure you've done anything at all.
>
> 1KDownload
Mats
It is true that the statement that "debug=true is a major security
risk" is in the next section in docs:"Getting Started", but
nevertheless that is a section after the user is encouraged to start
up the site with paster. May I humbly recommend also moving that
section up before the "Testing the template project" section, in
addition to the other suggestions in case the user does not read that
section of the documentation because they gleaned paster --reload
development.ini from somewhere else.
Sincerely,
Mats
Mike Orr
only on localhost by default. I've opened a ticket for it:
http://pylonshq.com/project/pylonshq/ticket/483
Mats brings up an important point, that if your development
workstation is accessible from the Internet, unintended users can
access your unfinished application. For most developers, being
limited to localhost is entirely sufficient. If developers do need to
share their unfinished app with colleagues on an internet or the
Internet can change their development.ini. But even then, there
should be a warning about putting it behind basic authentication and
SSL.
--
Mike Orr <slugg...@gmail.com>
Christoph Haas
> I am so glad that a concern plus two kind suggestions by a newcomer to
> the fine Pylons community, was addressed by sarcasm (paragraph 2) and
> "that I deserve to get hacked" (paragraph 3) as a response.
Sorry, I didn't mean to be harsh. But you sounded like you found the answer
while posting to the mailing list but wanted to complain anyway. The
warning is there. And if someone really deploys an application with debug
mode on (which means the default INI file was trashed) then that's what I
meant by "they deserve to get hacked". Like my father-in-law who clicks on
any warning dialog without even reading it. :)
> After further pondering, I feel this is a valid concern (not addressed
> in docs or startup script),
I second the idea to only bind the web server to localhost so nobody else
can access the application during development unless the developer
explicitly says so. But I'm contra disabling the beautiful interactive
debugger by default - people might miss it out accidentally and it's one
of the reasons I favor Pylons over anything else.
One thing I definitely second is that the documentation needs a little
going-over. So if you didn't find the deployment information in the first
place that's understandable.
Jonathan Vanasco
On Jul 6, 2:54 pm, "Mike Orr" <sluggos...@gmail.com> wrote:
> Hi all. I think a better solution is for devlopment.ini to listen
> only on localhost by default. I've opened a ticket for it:http://pylonshq.com/project/pylonshq/ticket/483
However, just to play devil's advocate - if you're tossing pylons
behind nginx/lighty/etc, you're going to be serving everything to
localhost -- even remote requests.
Mike Orr
Mats
Also thank you Mike for mentioning how to restrict allowed subnets --
I didn't realize that was an allowed-ip-addresses netmask; one might
consider renaming it to something other than 'host' (e.g.
'allowed_subnet 127.0.0.1 # (0.0.0.0 to allow any client on the
internet)') unless this is standard nomenclature.
Best wishes,
Mats
> 1KDownload
Jonathan Vanasco
On Jul 6, 5:56 pm, "Mike Orr" <sluggos...@gmail.com> wrote:
> So then we just need a reminder in the deployment options chapter.
I see the problem as this:
1- Pylons offers some great features to aid in debugging.
2- These features are necessary and make sense for being enabled at
start for the dev environment
3- They must be turned off for depoloyment
4- Most people will not read the docs straight through. What
developers do? They play or play + skim!
Personally, my ideal solution would be this:
1- add an 'allow_trackback_shell' debug option in the conf, have debug
enabled by default - but that option disabled
2- alter pylons.error.error_template to mention that
- - a - the trackback shell can be enabled/disabled
- - b - that this error page can be turned off by setting debug to
false
It's really just about making answers apparent to developers where
they're going to look for them. I can imagine no better place than
staring directly at them.
Mike Orr
> Also thank you Mike for mentioning how to restrict allowed subnets --
> I didn't realize that was an allowed-ip-addresses netmask; one might
> consider renaming it to something other than 'host' (e.g.
> 'allowed_subnet 127.0.0.1 # (0.0.0.0 to allow any client on the
> internet)') unless this is standard nomenclature.
I don't think you can use a network/netmask or multiple IPs; you can
just use an IP/domain name or the special address 0.0.0.0. I was
thinking of a situation where you're connected to both a local network
10.0.0.0 and the Internet; you could allow it to listen to the local
network.
The official addressing documentation is in the Python library
reference at the beginning of the socket module. The word 'host' is
traditional; I'm not sure 'listening_network' is any better. But
given that PasteDeploy is widely deployed with the current name,
renaming the variable would increase confusion.
But Python, Paste, and Pylons all need to document better what the
allowed values for 'host' are.
--
Mike Orr <slugg...@gmail.com>
Ian Bicking
policy for things like the exception handler. I wrote up a rough draft
of the policy here: http://wsgi.org/wsgi/Specifications/developer_auth
-- but I never got any feedback (on Web-SIG) and it kind of lost
momentum. I implemented an authenticator for it
(https://svn.openplans.org/svn/DevAuth/trunk) but I haven't added checks
in code like the exception handler.
It would probably be good to put a setting in evalexception to check for
this setting, and then when/if Pylons puts in some basic handler by
default (the simplest one would be a check that the connection was on
localhost) it can turn that setting on. This would make debug settings
generally less necessary.
--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org
Cliff Wells
That's what the X-Forwarded-For header is for. It must be checked in
addition to Remote-Addr.
Cliff
Damjan
> > Hi all. I think a better solution is for devlopment.ini to listen
> > only on localhost by default. I've opened a ticket for it:http://pylonshq.com/project/pylonshq/ticket/483
>
> That's a great idea -- and should be implemented!
>
> However, just to play devil's advocate - if you're tossing pylons
> behind nginx/lighty/etc, you're going to be serving everything to
> localhost -- even remote requests.
127.0.0.2 .. if this is the same for other platforms, you can set the
development.ini to 127.0.0.2, production on 0.0.0.0 or 127.0.0.1 :)
Mike Orr
That's what localnet is for -- all of 127.0.0.1 to 127.255.255.254 are
your own computer, for those occasions where you need 16,581,373
different IPs to test your new multiservice application (perhaps a
Twisted Names application). Well, it *was* assigned in the days
before IP scarcity.
Of course, never leave it to Microsoft to let a mere standard get in
it's way, so somebody with Windows will have to test whether it works
there.
In any case, we can't put something as nonstandard as 127.0.0.2 in the
default development.ini. A lot of users would look at that and think
it was a mistake. And there may be some platform somewhere where it
doesn't actually work.
--
Mike Orr <slugg...@gmail.com>
Wichert Akkerman
>
> On Mon, Jul 7, 2008 at 6:54 AM, Damjan <gda...@gmail.com> wrote:
> >
> >
> >> > Hi all. I think a better solution is for devlopment.ini to listen
> >> > only on localhost by default. I've opened a ticket for it:http://pylonshq.com/project/pylonshq/ticket/483
> >>
> >> That's a great idea -- and should be implemented!
> >>
> >> However, just to play devil's advocate - if you're tossing pylons
> >> behind nginx/lighty/etc, you're going to be serving everything to
> >> localhost -- even remote requests.
> >
> > On linux at least you can also setup an application to listen on
> > 127.0.0.2 .. if this is the same for other platforms, you can set the
> > development.ini to 127.0.0.2, production on 0.0.0.0 or 127.0.0.1 :)
>
> That's what localnet is for -- all of 127.0.0.1 to 127.255.255.254 are
> your own computer, for those occasions where you need 16,581,373
> different IPs to test your new multiservice application (perhaps a
> Twisted Names application). Well, it *was* assigned in the days
> before IP scarcity.
>
> Of course, never leave it to Microsoft to let a mere standard get in
> it's way, so somebody with Windows will have to test whether it works
> there.
I happened to be tinkering a bit on a XP test. A quick test showed
that you can at least ping the entire 127/8 address space in XP. I would
expect that you can bind to those addresses as well, but I couldn't
quickly test that (no python installed).
Wichert.
--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Chris AtLee
> default development.ini. A lot of users would look at that and think
> it was a mistake. And there may be some platform somewhere where it
> doesn't actually work.
FWIW, recent-ish Linux distributions have been putting entries similar
to this in /etc/hosts:
127.0.0.1 localhost
127.0.1.1 norval.mydomain.com norval
So gethostbyname("localhost") and gethostbyname(hostname()) return
different local addresses.
Cheers,
Chris