Re: capture exception

Okay, I can see that but we were talking specifically about eval. So, my examples were intended to showcase the two ways that eval can be called and not how to safely obtain data from the internet. On Tue, May 30, 2017 at 4:06 PM, Ruben Safir wrote: > On 05/30/2017 04:04 PM,

Re: capture exception

On 05/30/2017 04:04 PM, John Dunlap wrote: > In that example, the contents of $data are never evaluated by eval so > even if it can be "smashed"(whatever that means) eval would have nothing > to do with the failure. it means your bringing in data without a limit and you can smash the stack like

Re: capture exception

In that example, the contents of $data are never evaluated by eval so even if it can be "smashed"(whatever that means) eval would have nothing to do with the failure. On Tue, May 30, 2017 at 4:01 PM, Ruben Safir wrote: > On 05/30/2017 02:29 PM, John Dunlap wrote: > > eval {

Re: capture exception

On 05/30/2017 02:29 PM, John Dunlap wrote: > eval { > my $data = get_data_from_internet(); > }; $data needs to be scrubbed before using and you think you can't smash $data?? -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological

Re: capture exception

Let’s agree to differ -- Clive Eisen GPG: 75056DD0 > On 30 May 2017, at 19:36, Dirk-Willem van Gulik wrote: > > On 30 May 2017, at 19:52, Clive Eisen wrote: > >> From my servers - data >> >> From anyone else's - user input > > A few years

Re: capture exception

On 30 May 2017, at 19:52, Clive Eisen wrote: > From my servers - data > > From anyone else's - user input A few years ago - I would have agreed. Having seen the impact of things like the bash-exploit getting triggered from the data returned by a IP reverse lookup - I

Re: capture exception

More(and perhaps more confusing) examples: # SECURITY RISK eval qq{ my $data = get_data_from_internet(); }; if ($@) { # TODO: Handle errors } # SECURITY RISK eval q{ my $data = get_data_from_internet(); }; if ($@) { # TODO: Handle errors } # NOT A SECURITY RISK eval { my

Re: capture exception

With all due respect, Ruben, unless I'm totally missing something(which is totally possible), you're being a little alarmist. According to perldoc you can call eval with two different ways: - *eval EXPR* - *eval BLOCK* The first approach is inherently a security risk, as you have correctly

Re: capture exception

From my servers - data From anyone else's - user input -- Clive Eisen GPG: 75056DD0 > On 30 May 2017, at 18:47, Ruben Safir wrote: > > On Tue, May 30, 2017 at 05:10:17PM +0100, Clive Eisen wrote: >> It is only a security hole if you eval user input. >> > > > What

Re: capture exception

> > > I was just reading everyone's reply and now I am worried I created a > security hole. > eval will randomly execute ANY externally aquired string and run it with the full power and authority of Perl and your webserver. Nothing but static strings of known perl code should be using eval...

Re: capture exception

On Tue, May 30, 2017 at 05:10:17PM +0100, Clive Eisen wrote: > It is only a security hole if you eval user input. > What do you call return values from the internet? > > -- > Clive Eisen > GPG: 75056DD0 > > > > > > > > On 30 May 2017, at 17:00, Hiram Gibbard wrote:

Re: capture exception

It is only a security hole if you eval user input. -- Clive Eisen GPG: 75056DD0 > On 30 May 2017, at 17:00, Hiram Gibbard wrote: > > I might be hijacking this... Sorry, but...I recently used the Perl eval > function to determine if a ldap search returned a error or

Re: capture exception

At the risk of oversimplifying the issue: BAD: eval "MY CODE"; GOOD: eval {MY CODE}; On Tue, May 30, 2017 at 12:00 PM, Hiram Gibbard wrote: > I might be hijacking this... Sorry, but...I recently used the Perl eval > function to determine if a ldap search returned a error or

Re: capture exception

I might be hijacking this... Sorry, but...I recently used the Perl eval function to determine if a ldap search returned a error or not. Basically, a user's record has a attribute that points to a assistant, and If that assistant no longer exists the app was throwing a error since it executed a

Re: capture exception

> On 30 May 2017, at 16:58, p...@cpan.org wrote: > > On Tuesday 30 May 2017 15:53:13 James Smith wrote: >> String eval should be avoided at all costs [especially if you parse user >> input] - functional eval is different - and is a good model for catching >> errors etc > > Yes, string eval

Re: capture exception

On Tuesday 30 May 2017 15:53:13 James Smith wrote: > String eval should be avoided at all costs [especially if you parse user > input] - functional eval is different - and is a good model for catching > errors etc Yes, string eval should be avoided in all usage. But this discussion was about that

Re: capture exception

On 2017-05-30 03:49 PM, Dirk-Willem van Gulik wrote: On 30 May 2017, at 16:43, John Dunlap > wrote: How is it a security hole? …. > my $ret = eval { $m->...() }; Just imagine $m->…() returning something containing a valid perl expression

Re: capture exception

String eval should be avoided at all costs [especially if you parse user input] - functional eval is different - and is a good model for catching errors etc {There are some good uses of string eval - e.g. dymanically "use"ing modules} James On 2017-05-30 03:46 PM, Ruben Safir wrote:

Re: capture exception

https://www.effectiveperlprogramming.com/2011/03/know-the-different-evals/ On Tue, May 30, 2017 at 10:49 AM, Dirk-Willem van Gulik < di...@webweaving.org> wrote: > > On 30 May 2017, at 16:43, John Dunlap wrote: > > How is it a security hole? > > …. > > > my $ret = eval {

Re: capture exception

> On 30 May 2017, at 16:43, John Dunlap wrote: > > How is it a security hole? …. > > my $ret = eval { $m->...() }; Just imagine $m->…() returning something containing a valid perl expression such as " `rm -rf /‘; “, system(“rm -rf /“); or something that wires up a shell to a

Re: capture exception

On Tuesday 30 May 2017 10:46:08 Ruben Safir wrote: > Using eval is an unacceptable security bug for all online and public > access programs that aquire data from external non-secured sources. Eval is exception handling. It catch problems which could be security problem (like DOS attack) to

Re: capture exception

How so? How would an attacker exploit it? On Tue, May 30, 2017 at 10:46 AM, Ruben Safir wrote: > Using eval is an unacceptable security bug for all online and public > access programs that aquire data from external non-secured sources. > > > > On Tue, May 30, 2017 at

Re: capture exception

Using eval is an unacceptable security bug for all online and public access programs that aquire data from external non-secured sources. On Tue, May 30, 2017 at 09:39:53AM -0400, John Dunlap wrote: > Yes, I do that extensively and it works perfectly. It's as close to a true > Try/Catch block as

Re: capture exception

How is it a security hole? On Tue, May 30, 2017 at 10:41 AM, Ruben Safir wrote: > On Tue, May 30, 2017 at 09:47:59AM +0100, James Smith wrote: > > Not really a mod_perl question but you can always wrap your method > > call in an eval > > > > my $ret = eval { $m->...() }; > >

Re: capture exception

On Tue, May 30, 2017 at 09:47:59AM +0100, James Smith wrote: > Not really a mod_perl question but you can always wrap your method > call in an eval > > my $ret = eval { $m->...() }; > > And then check $@ for the error message > that is a security hole > > On 2017-05-26 02:08 AM, Peng

Re: capture exception

I think my head just exploded in a cloud of purple smoke. On Tue, May 30, 2017 at 10:03 AM, wrote: > Hi! > > Please note that true value in $@ is *not* necessary condition for > checking if error in eval occurred. And similarly empty string or logic > false value in $@ is *not*

Re: capture exception

Hi! Please note that true value in $@ is *not* necessary condition for checking if error in eval occurred. And similarly empty string or logic false value in $@ is *not* necessary condition that eval succeeded. The only thing which is guaranteed is undef return value from eval in case it failed.

Re: capture exception

Not really a mod_perl question but you can always wrap your method call in an eval my $ret = eval { $m->...() }; And then check $@ for the error message On 2017-05-26 02:08 AM, Peng Yonghua wrote: greeting, I am not so good at perl/modperl,:) In the handler, a method from a class was