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...
> 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.
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.
However I DID read the documentation: I read the first two sections
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.
Most likely not. =)
> 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. :)
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.
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.
> Cheers
> Christoph
> --
> When you do things right people won't be sure you've done anything at all.
> signature.asc
> 1KDownload
> 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. )
Addendum:
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
On Jul 5, 8:34 pm, Mats <mats.ahlg...@gmail.com> 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. )
> 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...
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.
> 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.
Cheers Christoph -- When you do things right people won't be sure you've done anything at all.
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 Sun, Jul 6, 2008 at 2:47 PM, Jonathan Vanasco <jonat...@findmeon.com> wrote:
> 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
> 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.
So then we just need a reminder in the deployment options chapter.
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
On Jul 6, 3:09 pm, Christoph Haas <em...@christoph-haas.de> wrote:
> > 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.
> Cheers
> Christoph
> --
> When you do things right people won't be sure you've done anything at all.
On Jul 6, 5:56 pm, "Mike Orr" <sluggos...@gmail.com> wrote:
> So then we just need a reminder in the deployment options chapter.
Yeah.
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.
On Sun, Jul 6, 2008 at 3:27 PM, Mats <mats.ahlg...@gmail.com> wrote: > 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.
Well, just for the record, I have been thinking about creating a general 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.
On Sun, 2008-07-06 at 14:47 -0700, Jonathan Vanasco wrote:
> 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
> 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.
That's what the X-Forwarded-For header is for. It must be checked in addition to Remote-Addr.
> 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 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.
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.
> >> 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 <wich...@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
> 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.
FWIW, recent-ish Linux distributions have been putting entries similar to this in /etc/hosts:
|
