[Tutor] Security [Was: Re: Decoding]
brunson at brunson.com
Tue Aug 14 22:34:51 CEST 2007
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
> 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
> 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.
More information about the Tutor