Re: [Tutor] Security [Was: Re: Decoding]
The point is that even though eval(raw_input()) is not a security threat, Alan's suggestion of myscript.py < some.txt might be. And even though the script written will not be a security issue, the *coding practice* that it teaches will lead to times when he does encounter that "tiny set of scenarios" in which the input for the script is potentially untrustworthy. Even though the risk is perhaps minimal to you, it still needs to be made known. An analogy is the threat of mercury, in which breathing the vapors can cumulatively lead to brain damage. However, in most quantities that people are freaking out over are far too small to be a threat. Don't go overboard, and yet *know* what is out there. I'll give an example. The boss gives two employees the simple jobs: You~ write a function grapher And You~ write an input file that graphs the common mathematical functions so that it can be run in his~ function grapher. The first guy uses eval to parse the text file because of its power. All he has to do is graph, eval takes care of turning the lines from the text file into function objects. The second notices the first guy's approach and sees a chance to move up in the world. He writes his file to his advantage. The two put the final result together and show the boss. The computer destroys important data that the company has worked on (not protected by the OS) and the first guy is fired because *his* program deleted stuff. Ouch. Be aware of security risks, not infatuated by them. eval() is not a risk by itself, but getting used to using it could lead to problems. Subtle things will always bite you more than things of which you are completely aware. JS ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
"Michael Sparks" <[EMAIL PROTECTED]> wrote > Yes, there are a tiny set of scenarios where doing > eval(raw_input(...)) could > be a problem. The idea that its always a gaping security hole is > completely > bogus. The number of scenarios is not tiny but the likelihood of attack by that route is small. However we live in a world where ever increasing numbers of people are deliberately trying to find such opportunities and exploit them. For example in my own organisation we have over 100,000 users and have basic spyware logging their PC activity and we have over 1,000 attempted attacks per month - and that's just the employees! Not all of that is malicious, some of it is just accidental mis-typing/clicking etc. But some is deliberate attempts to access things they shouldn't or just to see if they can break it - it can be boring working the night shift in a call centre! :-). The problem is real even if not enormous and all programmers have a duty to learn how to avoid it. And that includes not using such open doors to vandalism as eval() etc. While very few would trash their own computer there are plenty employees happy to trash the company computer, especially since it often leads to an easy few hours until the tech guys fix it! > The scenario's raised I've never once seen happen. As I say we see it on a monthly basis many times. > * Scenario A (and only that scenario) is hardly a risk considering > in >99% of cases where the user can type something in response > to > eval(raw_input(...)) they have FAR more ways of causing > problems. This is true, and eval() is not the main risk in this scenario it's true, but it does still constitute a risk if its input can be read from stdin. > Denouncing a piece of code as a gaping security hole without > discussing the context is irresponsible. No, neglecting to mention that it is a gaping security hole would be irresponsible. It would however be good to add a context about exactly when and how it is dangerous. In the case of eval() that is *anywhere* that untrusted or indeterminate input can be supplied. > After all piece of code is never a security risk by itself. It's how > that > code is deployed and used that _can_ be. Hmmm, I'm not sure I buy that. It's a bit like saying a gun is not a safety risk, it's only how it's used. But the very presence of the gun itself poses a risk that it will be abused. Same with risky code, if it makes a breach possible then it is itself a risk. If the risk matures then it's an issue, but one which may be too late to deal with! -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Whatever. I make it a point to discontinue any debate that degenerates into someone quoting their work experience to me. At that point you've basically told me that you are convinced you know better than I do and nothing I say will convince you otherwise, because you've been doing this for so long you couldn't possibly be wrong. No matter how many perfectly valid scenarios have been put forth, you've shot them down as being outlying border cases that can't compete with your assertion that if you have access to type at a keyboard, then your security is already compromised such that any damage done by eval(raw_input()) is trivial in comparison. I think the basic point that everyone has been making is: Using eval() on any uncontrolled input is a security risk, now matter what the source. Michael Sparks wrote: > On Tuesday 14 August 2007 16:48, Eric Brunson wrote: > ... > >> The only thing I can imagine is >> that you're stuck in some DOS mindset that if you're able to type into >> "the console" then you have ultimate access to the machine, which is not >> the case when using a true multi-user operating system like *nix or VMS. >> >> But, most strange to me is why you're this fired up over such a simple >> issue. It seems to me like just a misunderstanding. >> > > I'm not particularly fired up, text comes across much harsher than it looks. > (Also people being particularly patronising, like you have above, is > particularly irritating. Last time I used VMS was 12 years ago. I'm not > missing your point or anyone else's, and I've not used DOS for 10 years so > I'm hardly stuck in a DOS mindset (been developing under linux for over 10 > years). > > Yes, there are a tiny set of scenarios where doing eval(raw_input(...)) could > be a problem. The idea that its always a gaping security hole is completely > bogus. > > The scenario's raised I've never once seen happen. Despite having seen > a number of systems where you either ssh in or telnet into a specialise > console (routers and other network appliances). > > What was irritating was I was saying: >* Scenario A (and only that scenario) is hardly a risk considering > in >99% of cases where the user can type something in response to > eval(raw_input(...)) they have FAR more ways of causing problems. > >* The response I was getting a told was that this was wrong because > *other scenarios* were dangerous. > > Yes, other scenarios are wrong. Denouncing a piece of code as a gaping > security hole without discussing the context is irresponsible. > > That and being taught to suck eggs is irritating. I've been evaluating > security of network systems for 10 years and coding for 25 years. > > After all piece of code is never a security risk by itself. It's how that > code is deployed and used that _can_ be. > > > Michael. > > ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
On Tuesday 14 August 2007 16:48, Eric Brunson wrote: ... > The only thing I can imagine is > that you're stuck in some DOS mindset that if you're able to type into > "the console" then you have ultimate access to the machine, which is not > the case when using a true multi-user operating system like *nix or VMS. > > But, most strange to me is why you're this fired up over such a simple > issue. It seems to me like just a misunderstanding. I'm not particularly fired up, text comes across much harsher than it looks. (Also people being particularly patronising, like you have above, is particularly irritating. Last time I used VMS was 12 years ago. I'm not missing your point or anyone else's, and I've not used DOS for 10 years so I'm hardly stuck in a DOS mindset (been developing under linux for over 10 years). Yes, there are a tiny set of scenarios where doing eval(raw_input(...)) could be a problem. The idea that its always a gaping security hole is completely bogus. The scenario's raised I've never once seen happen. Despite having seen a number of systems where you either ssh in or telnet into a specialise console (routers and other network appliances). What was irritating was I was saying: * Scenario A (and only that scenario) is hardly a risk considering in >99% of cases where the user can type something in response to eval(raw_input(...)) they have FAR more ways of causing problems. * The response I was getting a told was that this was wrong because *other scenarios* were dangerous. Yes, other scenarios are wrong. Denouncing a piece of code as a gaping security hole without discussing the context is irresponsible. That and being taught to suck eggs is irritating. I've been evaluating security of network systems for 10 years and coding for 25 years. After all piece of code is never a security risk by itself. It's how that code is deployed and used that _can_ be. Michael. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Luke Paireepinart wrote: > Eric Brunson wrote: >> Michael Sparks wrote: >> >>> On Monday 13 August 2007 21:53, Kent Johnson wrote: >>> Hmm...could be a remote connection such as ssh, which precludes the sledgehammer though probably not the sort of mischief you can get into with eval()...perhaps there are untrusted remote connections where eval() would still be a significant risk, I don't know... >>> If they can ssh into a box, the likelihood of that ssh connection >>> *only* allowing them access to run that single python program >>> strikes me as vanishingly small :-) >>> >>> >> >> Unless you set it up that way specifically, i.e. making the >> interactive python program their login shell or specifying it to be >> run in their .ssh/config. >> >> >> P.S. >> Michael, sorry for the double post to you, I missed the "reply all" >> button the first time. >> > I don't think you missed on account of me receiving two e-mails as > well. :) > -Luke Python: easy Email: hard ;-) ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Eric Brunson wrote: > Michael Sparks wrote: > >> On Monday 13 August 2007 21:53, Kent Johnson wrote: >> >> >>> Hmm...could be a remote connection such as ssh, which precludes the >>> sledgehammer though probably not the sort of mischief you can get into >>> with eval()...perhaps there are untrusted remote connections where >>> eval() would still be a significant risk, I don't know... >>> >>> >> If they can ssh into a box, the likelihood of that ssh connection *only* >> allowing them access to run that single python program strikes me as >> vanishingly small :-) >> >> >> > > Unless you set it up that way specifically, i.e. making the interactive > python program their login shell or specifying it to be run in their > .ssh/config. > > > P.S. > Michael, sorry for the double post to you, I missed the "reply all" > button the first time. > I don't think you missed on account of me receiving two e-mails as well. :) -Luke ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
"Michael Sparks" <[EMAIL PROTECTED]> wrote > You are COMPLETELY missing the point. The __following__ code > >> >> > foo = raw_input(...) >> >> > x = eval(foo) > > ONLY works if the user has console access to the machine. Actually no. It applies to stdin which could be a console or a file. I agree that raw_input is *usually* applicable to a console but $ python myscript.py < mydirtydata.txt will leave me open to all sorts of vulnerabilities. And if the python script is embedded within a shell script then this scenario becomes quite common and a valid security threat. Regards, -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Michael Sparks wrote: > On Monday 13 August 2007 21:53, Kent Johnson wrote: > >> Hmm...could be a remote connection such as ssh, which precludes the >> sledgehammer though probably not the sort of mischief you can get into >> with eval()...perhaps there are untrusted remote connections where >> eval() would still be a significant risk, I don't know... >> > > If they can ssh into a box, the likelihood of that ssh connection *only* > allowing them access to run that single python program strikes me as > vanishingly small :-) > > Unless you set it up that way specifically, i.e. making the interactive python program their login shell or specifying it to be run in their .ssh/config. P.S. Michael, sorry for the double post to you, I missed the "reply all" button the first time. > Generally speaking I agree that eval is a good opportunity for problems, but > if its in response to raw_input, I think the likelihood of it being the > biggest potential security problem is low :) > > (After all, if they're ssh'ing in, they're more likely to ssh in, *then* run > the code. They could happily delete and trash all sorts of things either > inside or outside python. They could even write their own scripts to assist > them in their devilish plans too, far exceeding the minor demon of eval ;-) > > Eval can however be an amazingly useful function, especially when combined > with exec. > > > Michael. > ___ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Michael Sparks wrote: > On Monday 13 August 2007 21:53, Kent Johnson wrote: > >> Hmm...could be a remote connection such as ssh, which precludes the >> sledgehammer though probably not the sort of mischief you can get into >> with eval()...perhaps there are untrusted remote connections where >> eval() would still be a significant risk, I don't know... >> > > If they can ssh into a box, the likelihood of that ssh connection *only* > allowing them access to run that single python program strikes me as > vanishingly small :-) > Unless you set it up that way specifically, i.e. making the interactive python program their login shell or specifying it to be run in their .ssh/config. > Generally speaking I agree that eval is a good opportunity for problems, but > if its in response to raw_input, I think the likelihood of it being the > biggest potential security problem is low :) > > (After all, if they're ssh'ing in, they're more likely to ssh in, *then* run > the code. They could happily delete and trash all sorts of things either > inside or outside python. They could even write their own scripts to assist > them in their devilish plans too, far exceeding the minor demon of eval ;-) > > Eval can however be an amazingly useful function, especially when combined > with exec. > > > Michael. > ___ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Michael Sparks wrote: > Tiger12506, > > > You are COMPLETELY missing the point. The __following__ code > > > foo = raw_input(...) > x = eval(foo) > > > ONLY works if the user has console access to the machine. > > If they have console access to the machine > AND you're worried about them damaging it > THEN an eval(raw_input( ...)) construct is the least of your worries. > > I'm not referring to text taken from >* a network connection >* a file >* a web form >* a P2P network > > I was JUST referring to the ONE context of immediately eval'ing user input. > (an unlikely one at that) > No, I think you're missing the point. If the program was not interacting with the user through the console, then why would you be using raw_input()? raw_input() is used to get user input from the controlling terminal. Am I missing some other use for raw_input()? Using eval() on untrusted input of any kind is a security risk. Reading the rest of your email, I get the feeling that what you're saying is: if a user has access to "the console", then using eval( raw_input() ) is the least of your worries because the person can do anything they want. Is that your assertion? If it is, then it's an invalid argument. raw_input() is not only useful on "the console", it can be used to interact with any terminal and can be done securely so that exiting the program is either impossible, or restarts the program or else simply disconnects from the terminal and leaves the user with no access at all. The only thing I can imagine is that you're stuck in some DOS mindset that if you're able to type into "the console" then you have ultimate access to the machine, which is not the case when using a true multi-user operating system like *nix or VMS. But, most strange to me is why you're this fired up over such a simple issue. It seems to me like just a misunderstanding. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Tiger12506,
You are COMPLETELY missing the point. The __following__ code
> >> > foo = raw_input(...)
> >> > x = eval(foo)
ONLY works if the user has console access to the machine.
If they have console access to the machine
AND you're worried about them damaging it
THEN an eval(raw_input( ...)) construct is the least of your worries.
I'm not referring to text taken from
* a network connection
* a file
* a web form
* a P2P network
I was JUST referring to the ONE context of immediately eval'ing user input.
(an unlikely one at that)
Where you say this:
> But if you parse a text file that you haven't reviewed... that's possible.
You're talking about a completely different context. Taking data from a
network socket and using eval there is again a different context from above.
Using it as a generic data conversion tool is again a different context.
In those 3 contexts, yes, anyone would agree that using eval is extremely
unwise at best. In the context of evaluating something which someone types at
a console though?
On Tuesday 14 August 2007 02:28, Tiger12506 wrote:
> > On Monday 13 August 2007 22:39, Tiger12506 wrote:
> >> > foo = raw_input(...)
> >> > x = eval(foo)
> >
> > ...
> >
> >> Let your program run on your machine and I'll walk by, type in this
> >> string,
> >> and hit enter. We'll see how much of an exception it is when you can't
> >> boot
> >> your XP machine anymore.
> >> ;-)
> >
> > Who cares? I don't run XP :-D
>
> I'm sure the equivalent can be done on different operating systems.
Actually, decent operating systems prevent that sort of problem. A way to
trash a linux machine would be to wipe /lib/libc.* on Mac OS X ,
wipe /usr/lib/libc.dylib .
Let's see if it works on a linux machine:
>>> file("/lib/libc.so.6","w").close()
Traceback (most recent call last):
File "", line 1, in
IOError: [Errno 13] Permission denied: '/lib/libc.so.6'
How about on a Mac OS X machine:
>>> file("/usr/lib/libc.dylib", "w").close()
Traceback (most recent call last):
File "", line 1, in ?
IOError: [Errno 13] Permission denied: '/usr/lib/libc.dylib'
Yes, of course if I was logged in as root on either it'd work. I could do far
more damage far more easily though if I was.
> > Seriously though, if typing:
> >> "file('boot.ini','w').close()"
> >
> > Into an "eval prompt" worked then equally leaving a python interpreter
> > open
> > would be dumb, let alone a console.
>
> It does work. Try it with a simple file "temp.txt" for example. You can run
> any function call if the string is parsed with eval. Notice I did not say
> "type into an eval prompt type loop" I mean entirely if the string is
> parsed with eval.
I know just how powerful eval is. It's damn usefully powerful.
You have changed the context here from the context I was talking about.
I was stating that *IF* the following can cause damage:
> >> > foo = raw_input(...)
> >> > x = eval(foo)
*AND* you are worried about that damage *BECAUSE* you believe the user is
malicious, THEN the above code is the least of your worries.
> > Quite frankly anyone getting worried about this:
> >> > foo = raw_input(...)
> >> > x = eval(foo)
> >
> > Is pretty over anxious IMO. "Gosh, the person at the console might be
> > able to
> > get python do something which they can do anyway".
>
> Again. Anytime the function is parsed with eval, you can run *any* python
> function that is in the scope that the eval function is being executed
> from. Security risks are never simple. Of course they can do it with a
> python console window open. But if you are worried about security you don't
> allow them access to the python console. You ecapsulate it.
Yes, I know. I was talking solely about a context where they clearly DO have
access to the console, and that worrying about this was the least of your
worries.
It's like saying "you left the door unlocked, you're going to get robbed",
when you're missing that the people you're not trusting are inside the house
watching the TV & drinking your coffee and you're leaving them there alone.
Leaving the doors on a house unlocked is generally unwise when you go out (not
least due to invalidating insurance). It's totally irrelevant if you leave it
with people in the house you expect to rob you.
> But what if you
> use eval in a library function you write, which is used to parse some
> input? Peer to peer networks, http servers, even text files that you try to
> parse could be corrupted to cause your computer damage.
These are ALL different contexts from the one I was talking about. None
of these example are this context:
> >> > foo = raw_input(...)
> >> > x = eval(foo)
I maintain that this: eval(raw_input(...)) in the vast majority of cases is as
safe as letting the user have access to the machine in the first place.
Your examples here:
> use eval in a library function you write, which is used to parse some
> input? Peer to peer networks, http servers, even text files that you try to
> parse coul
Re: [Tutor] Security [Was: Re: Decoding]
I guess i will start out with your tutorial, hope it won't get as difficult as the previous one :-) thanks On 8/14/07, Alan Gauld <[EMAIL PROTECTED]> wrote: > > > "Khamid Nurdiev" <[EMAIL PROTECTED]> wrote > > > This book by M. Zelle is getting really difficult shortly > > after that section > > I can't comment on the specific book but unfortunately its > a common phenomenon that "beginner" books start of easy > then suddenly get much harder. This is partly because it is > very hard for an experienced programmer to think like a true > beginner, there is just so much we take for granted as obvious. > > > the recommendations on books for beginners i have ordered the book > > "Core > > Python Programming" by Wesley Chun, so comparing those two books > > which one > > is more suitable (recommended) for a beginner to both python and > > programming? > > Wes' book is a very good book on Python, personally I think it might > be quite fast paced and detailed for a beginner to programming but > there are plenty tutorials on the web for that, including mine! :-) > > > Here in our local library, the first edition of "Core python > > programming" > > is available so i guess i will use it till I receive the second > > edition, ... > > . Is there much difference between the first and second editions? > > In the detauil yes but not in the fundamental principles. Especially > the early chapters seem pretty similar. Mind you I've only looked > at the second edition in depth, I've only seen the first edition in > book > stores... > > > also one more book, i haven't ordered it yet, is the "Python from > > novice to > > professional" by Magnus Lie Hetland, is it worth ordering and > > studying for a > > complete noob? > > No idea but you really don't want too many introductory texts, > you will rarely look at them once you learn how to program. > (Wes' book is a good exception since he has a lot of "under the > covers" > stuff about how python works which even experienced pythonistas can > use) > > HTH, > > -- > Alan Gauld > Author of the Learn to Program web site > http://www.freenetpages.co.uk/hp/alan.gauld > > > ___ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
> > The original poster posted a post with the following function:
> > def dec():
> > import string
> > message=raw_input("Enter the message to decode: ")
> > result=''
> > for x in string.split(message):
> > result=result+chr(eval(x))
> > return result
> >
> > print dec()
i echo everyone else's sentiments on the use of eval(), esp. in this
example. it seems like it was created in the old Python 1.x days. a
useful exercise for everyone here is to figure out what this piece of
code is supposed to do, and refactor it so that it's safer and easier
to understand. my suggestions would include:
- remove reference to the string module and just use (string) methods
- remove eval()
- put together the string without using concatenation
something like this would be better:
result = ''.join([chr(x) for x in message.split()])
also, i think that user interaction should be kept out of "calculation
functions." by that i mean that you can have code that does
raw_input() and print, but the core functionality should just take
input, say 'message' and return an object, all without user
interaction. that way, you can reuse your code more easily in other
applications where you desire this functionality.
cheers,
-- wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
http://corepython.com
wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
> On Monday 13 August 2007 22:39, Tiger12506 wrote:
>> > foo = raw_input(...)
>> > x = eval(foo)
>> >
> ...
>> Let your program run on your machine and I'll walk by, type in this
>> string,
>> and hit enter. We'll see how much of an exception it is when you can't
>> boot
>> your XP machine anymore.
>> ;-)
>
> Who cares? I don't run XP :-D
I'm sure the equivalent can be done on different operating systems.
> Also, a broken XP machine is an opportunity anyway, not a problem.
Agreed.
> Seriously though, if typing:
>
>> "file('boot.ini','w').close()"
>
> Into an "eval prompt" worked then equally leaving a python interpreter
> open
> would be dumb, let alone a console.
It does work. Try it with a simple file "temp.txt" for example. You can run
any function call if the string is parsed with eval. Notice I did not say
"type into an eval prompt type loop" I mean entirely if the string is parsed
with eval.
> Oddly my desktop machine often has a shell open, and often has a python
> interpreter running as well. Indeed at present it has 11 shells open. The
> non
> graphical console is a root shell (accessible by alt-f1). My work machines
> likewise have around a dozen shells open each.
>
> However, when I leave my machine alone the display locks itself, and its
> normally behind a locked door (unless I'm with it).
>
> Quite frankly anyone getting worried about this:
>
>> > foo = raw_input(...)
>> > x = eval(foo)
>
> Is pretty over anxious IMO. "Gosh, the person at the console might be able
> to
> get python do something which they can do anyway".
Again. Anytime the function is parsed with eval, you can run *any* python
function that is in the scope that the eval function is being executed from.
Security risks are never simple. Of course they can do it with a python
console window open. But if you are worried about security you don't allow
them access to the python console. You ecapsulate it. But what if you use
eval in a library function you write, which is used to parse some input?
Peer to peer networks, http servers, even text files that you try to parse
could be corrupted to cause your computer damage.
The point is that eval is a security risk "greater than other
implementations" that is-using int() is much more secure than eval().
> (This is rather distinct from taking random crap from someone not on the
> local
> console and just doing it (eg from a network connection/external
> resource))
>
> If the user wishes to trash their own machine, using an eval prompt is a
> rather bizarre way to go about it.
Sometimes it's not what they want to do. Kiosks centers are a good example.
But if you parse a text file that you haven't reviewed... that's possible.
Not likely. But possible. It's along the same lines as buffer overruns. It's
possible. Not as likely. But possible.
JS
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
On Monday 13 August 2007 22:39, Tiger12506 wrote:
> > foo = raw_input(...)
> > x = eval(foo)
> >
...
> Let your program run on your machine and I'll walk by, type in this string,
> and hit enter. We'll see how much of an exception it is when you can't boot
> your XP machine anymore.
> ;-)
Who cares? I don't run XP :-D
Also, a broken XP machine is an opportunity anyway, not a problem.
Seriously though, if typing:
> "file('boot.ini','w').close()"
Into an "eval prompt" worked then equally leaving a python interpreter open
would be dumb, let alone a console.
Oddly my desktop machine often has a shell open, and often has a python
interpreter running as well. Indeed at present it has 11 shells open. The non
graphical console is a root shell (accessible by alt-f1). My work machines
likewise have around a dozen shells open each.
However, when I leave my machine alone the display locks itself, and its
normally behind a locked door (unless I'm with it).
Quite frankly anyone getting worried about this:
> > foo = raw_input(...)
> > x = eval(foo)
Is pretty over anxious IMO. "Gosh, the person at the console might be able to
get python do something which they can do anyway".
(This is rather distinct from taking random crap from someone not on the local
console and just doing it (eg from a network connection/external resource))
If the user wishes to trash their own machine, using an eval prompt is a
rather bizarre way to go about it.
Michael.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
"Khamid Nurdiev" <[EMAIL PROTECTED]> wrote > This book by M. Zelle is getting really difficult shortly > after that section I can't comment on the specific book but unfortunately its a common phenomenon that "beginner" books start of easy then suddenly get much harder. This is partly because it is very hard for an experienced programmer to think like a true beginner, there is just so much we take for granted as obvious. > the recommendations on books for beginners i have ordered the book > "Core > Python Programming" by Wesley Chun, so comparing those two books > which one > is more suitable (recommended) for a beginner to both python and > programming? Wes' book is a very good book on Python, personally I think it might be quite fast paced and detailed for a beginner to programming but there are plenty tutorials on the web for that, including mine! :-) > Here in our local library, the first edition of "Core python > programming" > is available so i guess i will use it till I receive the second > edition, ... > . Is there much difference between the first and second editions? In the detauil yes but not in the fundamental principles. Especially the early chapters seem pretty similar. Mind you I've only looked at the second edition in depth, I've only seen the first edition in book stores... > also one more book, i haven't ordered it yet, is the "Python from > novice to > professional" by Magnus Lie Hetland, is it worth ordering and > studying for a > complete noob? No idea but you really don't want too many introductory texts, you will rarely look at them once you learn how to program. (Wes' book is a good exception since he has a lot of "under the covers" stuff about how python works which even experienced pythonistas can use) HTH, -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
On Mon, 13 Aug 2007, Alan Gauld wrote: > eval() > exec() > execfile() > input() Two of my favorite things about Python 3000 will be having input() go away and fixing integer division. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
On Monday 13 August 2007 21:53, Kent Johnson wrote: > Hmm...could be a remote connection such as ssh, which precludes the > sledgehammer though probably not the sort of mischief you can get into > with eval()...perhaps there are untrusted remote connections where > eval() would still be a significant risk, I don't know... If they can ssh into a box, the likelihood of that ssh connection *only* allowing them access to run that single python program strikes me as vanishingly small :-) Generally speaking I agree that eval is a good opportunity for problems, but if its in response to raw_input, I think the likelihood of it being the biggest potential security problem is low :) (After all, if they're ssh'ing in, they're more likely to ssh in, *then* run the code. They could happily delete and trash all sorts of things either inside or outside python. They could even write their own scripts to assist them in their devilish plans too, far exceeding the minor demon of eval ;-) Eval can however be an amazingly useful function, especially when combined with exec. Michael. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Khamid Nurdiev wrote: > It is Good that you have the book because i have a few questions > concerning the books again. This book by M. Zelle is getting really > difficult shortly after that section (also as i see the examples are > getting fewer) but it was easy till that part, so the question is: is > it to me or is the rest of the book indeed explained not well(not like > the beginning parts)?. Having heard the recommendations on books for > beginners i have ordered the book "Core Python Programming" by Wesley > Chun, so comparing those two books which one is more suitable > (recommended) for a beginner to both python and programming? I haven't read either book, but if nothing else, it helps that Wes is a regular here at [tutor]. > Here in our local library, the first edition of "Core python > programming" is available so i guess i will use it till I receive the > second edition, but i think it might take like a month, if not more > till it gets to where i live. Is there much difference between the > first and second editions? And also one more book, i haven't ordered > it yet, is the "Python from novice to professional" by Magnus Lie > Hetland, is it worth ordering and studying for a complete noob? > > thanks for your answers. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Michael Sparks wrote: >> Anything where user input is executed as code is a security hole and >> should never be opened to untrusted users. > > foo = raw_input(...) > x = eval(foo) > > Is an exception, in almost[*] every scenario I can think of. (and is the > context eval was being used as far as I can see without reading the whole > thread) > > Why? Because if they can type on the keyboard of a machine that's running > raw_input they have the ability to do far more damage that way than any > other. (ability to use a real sledgehammer on the machine springs to mind > :-) Hmm...could be a remote connection such as ssh, which precludes the sledgehammer though probably not the sort of mischief you can get into with eval()...perhaps there are untrusted remote connections where eval() would still be a significant risk, I don't know... Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
> foo = raw_input(...)
> x = eval(foo)
>
> Is an exception, in almost[*] every scenario I can think of. (and is the
> context eval was being used as far as I can see without reading the whole
> thread)
>
> [*] One scenario that seems unlikely but possible is a scenario where a
> machine has been put into a form of kiosk mode where the *only*
> thing
> they can do is type responses to the raw_input prompt. Given where
> raw_input runs, this strikes me as highly unrealistic/unlikely.
>
> Why? Because if they can type on the keyboard of a machine that's running
> raw_input they have the ability to do far more damage that way than any
> other. (ability to use a real sledgehammer on the machine springs to mind
> :-)
Let your program run on your machine and I'll walk by, type in this string,
and hit enter. We'll see how much of an exception it is when you can't boot
your XP machine anymore.
;-)
"file('boot.ini','w').close()"
Of course, x would be set to None (the return value of the file method
close()), but the damage is already done.
btw - that *one scenario* happens a lot more often than you think. For
example, you write a library. It doesn't have to be raw_input. You could get
that string from anywhere. A text box, a username. A registry value!! If
your program uses eval on a registry string, someone could set that key
before hand to something similar to above.
JS
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
It is Good that you have the book because i have a few questions concerning
the books again. This book by M. Zelle is getting really difficult shortly
after that section (also as i see the examples are getting fewer) but it was
easy till that part, so the question is: is it to me or is the rest of the
book indeed explained not well(not like the beginning parts)?. Having heard
the recommendations on books for beginners i have ordered the book "Core
Python Programming" by Wesley Chun, so comparing those two books which one
is more suitable (recommended) for a beginner to both python and
programming?
Here in our local library, the first edition of "Core python programming"
is available so i guess i will use it till I receive the second edition, but
i think it might take like a month, if not more till it gets to where i
live. Is there much difference between the first and second editions? And
also one more book, i haven't ordered it yet, is the "Python from novice to
professional" by Magnus Lie Hetland, is it worth ordering and studying for a
complete noob?
thanks for your answers.
On 8/13/07, Kent Johnson <[EMAIL PROTECTED]> wrote:
>
> bhaaluu wrote:
>
> > The original poster posted a post with the following function:
> > def dec():
> > import string
> > message=raw_input("Enter the message to decode: ")
> > result=''
> > for x in string.split(message):
> > result=result+chr(eval(x))
> > return result
> >
> > print dec()
> > which is from the book:
> > "Python programming: An introduction to CS" by John M. Zelle.
> >
> > As a Python Noob, I'm obviously ignorant of most of the Python
> > language, but I wonder why the author of a book would include
> > a function that is a "gaping security hole," when the int() function
> > would do the job just as nicely, and without the security concerns?
>
> I can't answer for Mr Zelle. Looking at the book, he introduces int(),
> float() and long() shortly after the section containing the above example.
> >
> > Of course, I don't know what context the snippet is in because I
> > don't have a copy of the book in question. But as a Python Noob,
> > I really do appreciate your heads-up about eval(), and I have it
> > red-flagged as a 'gaping security' concern, and will use it with
> > extreme caution in the future. =)
>
> Good. There is almost always a better way to accomplish a task than to
> use eval().
>
> > Now for MY question: Besides eval(), are there other functions that
> > should be 'red-flagged' as well? I just haven't been around Python
> > long enough yet to become familiar with all of the Standard Library.
> > Correct me if I'm wrong, but with 29 keywords, and over 176 library
> > functions, Python weighs-in at over 200 Standard "objects"?
>
> Anything where user input is executed as code is a security hole and
> should never be opened to untrusted users.
> eval()
> exec
> execfile()
>
> come to mind.
>
> Kent
> ___
> Tutor maillist - Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
"bhaaluu" <[EMAIL PROTECTED]> wrote > Now for MY question: Besides eval(), are there other functions that > should be 'red-flagged' as well? Pretty much anything that can execute user entered code is a potential security problem. The most common are probably: eval() exec() execfile() input() All of these execute code one way or another and unless you are absolutely sure that the code couldn't be malicious you should avoid using them. In most cases thee are safer alternatives. BTW All are fine for prototyping ideas, experimenting at the >>> prompt etc and can save you some typing. But if you then want to turn your idea into a script think about changing these functions to something safer. Also in databases using string substitution instead of the DBAPI substitution can allow SQL injection attacks. See my database topic in my tutor for more on that one. Search for the heading: A Word about Security I'm sure others will bring up other examples but these are the ones we see most often on this list. HTH, Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
On Monday 13 August 2007 15:28, Kent Johnson wrote:
> > The original poster posted a post with the following function:
...
> > message=raw_input("Enter the message to decode: ")
> > result=''
> > for x in string.split(message):
> > result=result+chr(eval(x))
> Anything where user input is executed as code is a security hole and
> should never be opened to untrusted users.
foo = raw_input(...)
x = eval(foo)
Is an exception, in almost[*] every scenario I can think of. (and is the
context eval was being used as far as I can see without reading the whole
thread)
[*] One scenario that seems unlikely but possible is a scenario where a
machine has been put into a form of kiosk mode where the *only* thing
they can do is type responses to the raw_input prompt. Given where
raw_input runs, this strikes me as highly unrealistic/unlikely.
Why? Because if they can type on the keyboard of a machine that's running
raw_input they have the ability to do far more damage that way than any
other. (ability to use a real sledgehammer on the machine springs to mind
:-)
Michael.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
bhaaluu wrote:
> The original poster posted a post with the following function:
> def dec():
> import string
> message=raw_input("Enter the message to decode: ")
> result=''
> for x in string.split(message):
> result=result+chr(eval(x))
> return result
>
> print dec()
> which is from the book:
> "Python programming: An introduction to CS" by John M. Zelle.
>
> As a Python Noob, I'm obviously ignorant of most of the Python
> language, but I wonder why the author of a book would include
> a function that is a "gaping security hole," when the int() function
> would do the job just as nicely, and without the security concerns?
I can't answer for Mr Zelle. Looking at the book, he introduces int(),
float() and long() shortly after the section containing the above example.
>
> Of course, I don't know what context the snippet is in because I
> don't have a copy of the book in question. But as a Python Noob,
> I really do appreciate your heads-up about eval(), and I have it
> red-flagged as a 'gaping security' concern, and will use it with
> extreme caution in the future. =)
Good. There is almost always a better way to accomplish a task than to
use eval().
> Now for MY question: Besides eval(), are there other functions that
> should be 'red-flagged' as well? I just haven't been around Python
> long enough yet to become familiar with all of the Standard Library.
> Correct me if I'm wrong, but with 29 keywords, and over 176 library
> functions, Python weighs-in at over 200 Standard "objects"?
Anything where user input is executed as code is a security hole and
should never be opened to untrusted users.
eval()
exec
execfile()
come to mind.
Kent
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Security [Was: Re: Decoding]
Greetings,
Although it is considered bad form to answer one's own post,
I'm going to do so anyway, anyhow,
http://docs.python.org/lib/built-in-funcs.html
It turns out that both eval() and int() are Python interpreter
built-ins. Now I really wonder why the author of the book
used eval() rather than int() in the book's example?
> The original poster posted a post with the following function:
> def dec():
> import string
> message=raw_input("Enter the message to decode: ")
> result=''
> for x in string.split(message):
> result=result+chr(eval(x))
> return result
>
> print dec()
> which is from the book:
> "Python programming: An introduction to CS" by John M. Zelle.
--
bhaaluu at gmail dot com
On 8/13/07, bhaaluu <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> On 8/12/07, Kent Johnson <[EMAIL PROTECTED]> wrote:
> > bhaaluu wrote:
> > >
> > print chr(eval('65'))
> > > A
> >
> > There is no need to use eval() here. Since the expected values are
> > integers, just use int():
> > In [6]: chr(int('65'))
> > Out[6]: 'A'
> >
> > This gives a clearer error message when the input is not as expected:
> > In [7]: chr(int('How'))
> >
> > Traceback (most recent call last):
> >File "", line 1, in
> > : invalid literal for int() with base 10:
> > 'How'
> >
> > In general it's a good idea to avoid using eval() especially with user
> > input, it is a gaping security hole.
> >
> > Kent
>
> The original poster posted a post with the following function:
> def dec():
> import string
> message=raw_input("Enter the message to decode: ")
> result=''
> for x in string.split(message):
> result=result+chr(eval(x))
> return result
>
> print dec()
> which is from the book:
> "Python programming: An introduction to CS" by John M. Zelle.
>
> As a Python Noob, I'm obviously ignorant of most of the Python
> language, but I wonder why the author of a book would include
> a function that is a "gaping security hole," when the int() function
> would do the job just as nicely, and without the security concerns?
>
> Of course, I don't know what context the snippet is in because I
> don't have a copy of the book in question. But as a Python Noob,
> I really do appreciate your heads-up about eval(), and I have it
> red-flagged as a 'gaping security' concern, and will use it with
> extreme caution in the future. =)
>
> Now for MY question: Besides eval(), are there other functions that
> should be 'red-flagged' as well? I just haven't been around Python
> long enough yet to become familiar with all of the Standard Library.
> Correct me if I'm wrong, but with 29 keywords, and over 176 library
> functions, Python weighs-in at over 200 Standard "objects"?
>
> Cheers! =)
> --
> bhaaluu at gmail dot com
>
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
[Tutor] Security [Was: Re: Decoding]
Greetings,
On 8/12/07, Kent Johnson <[EMAIL PROTECTED]> wrote:
> bhaaluu wrote:
> >
> print chr(eval('65'))
> > A
>
> There is no need to use eval() here. Since the expected values are
> integers, just use int():
> In [6]: chr(int('65'))
> Out[6]: 'A'
>
> This gives a clearer error message when the input is not as expected:
> In [7]: chr(int('How'))
>
> Traceback (most recent call last):
>File "", line 1, in
> : invalid literal for int() with base 10:
> 'How'
>
> In general it's a good idea to avoid using eval() especially with user
> input, it is a gaping security hole.
>
> Kent
The original poster posted a post with the following function:
def dec():
import string
message=raw_input("Enter the message to decode: ")
result=''
for x in string.split(message):
result=result+chr(eval(x))
return result
print dec()
which is from the book:
"Python programming: An introduction to CS" by John M. Zelle.
As a Python Noob, I'm obviously ignorant of most of the Python
language, but I wonder why the author of a book would include
a function that is a "gaping security hole," when the int() function
would do the job just as nicely, and without the security concerns?
Of course, I don't know what context the snippet is in because I
don't have a copy of the book in question. But as a Python Noob,
I really do appreciate your heads-up about eval(), and I have it
red-flagged as a 'gaping security' concern, and will use it with
extreme caution in the future. =)
Now for MY question: Besides eval(), are there other functions that
should be 'red-flagged' as well? I just haven't been around Python
long enough yet to become familiar with all of the Standard Library.
Correct me if I'm wrong, but with 29 keywords, and over 176 library
functions, Python weighs-in at over 200 Standard "objects"?
Cheers! =)
--
bhaaluu at gmail dot com
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
