in reply to Re: Arithmetic with fractions
in thread Arithmetic with fractions

This function should be safe to use as it will only do the eval if the string contains + - . 0 1 2 3 4 5 6 7 8 9 / plus spaces and tabs which are harmless.

It is safer than an unchecked eval, but not completely safe or devoid of side effects. An attacker could:

a) Cause the eval to throw an exception with input like 5++ or 4/0. This could in turn make the whole program die or misbehave in certain situation, and has the side effects of triggering the signal handlers and clobbering $@, in addition to making the eval return undef.

b) Test certain numeric patterns against $_ or even compute its value. For example, the following input makes the eval return the value of $_, if it's an integer in the range 0..99.

/1//1+/2//0.5+/3//0.333333333333333+/4//0.25+/5//0.2+/6// 0.166666666666667+/7//0.142857142857143+/8//0.125+/9// 0.111111111111111+/1.//0.1-/1.//1+/2.//0.05-/2.//0.5+/3.// 0.0333333333333333-/3.//0.333333333333333+/4.//0.025-/4.// 0.25+/5.//0.02-/5.//0.2+/6.//0.0166666666666667-/6.// 0.166666666666667+/7.//0.0142857142857143-/7.// 0.142857142857143+/8.//0.0125-/8.//0.125+/9.// 0.0111111111111111-/9.//0.111111111111111+/11//1+/22// 0.5+/33//0.333333333333333+/44//0.25+/55//0.2+/66// 0.166666666666667+/77//0.142857142857143+/88//0.125+/ 99//0.111111111111111

c) I DON'T KNOW if it's possible to create a regexp that takes forever to run only with the allowed characters.

Replies are listed 'Best First'.
Re^3: Arithmetic with fractions
by ikegami (Patriarch) on Sep 22, 2004 at 15:41 UTC

    a) eval does not throw exceptions. (Quite the opposite.) Given those strings, undef will be returned, which sounds perfectly acceptable. It should also return undef when validation fails, but it doesn't.

    b) While this function returning a number in 0..99 doesn't sound dangerous, I have to figure how this happens.

    c) Shouldn't you be asking: Is it possible to make THAT regexp take forever? After all, the user isn't providing the regexp. If that simple regexp can take forever, Perl is in big trouble, not just this program.

      eval does not throw exceptions (Quite the opposite.)

      Would "An attacker could supply input that would genereate compile and run-time errors inside a string eval" be a more appropriate wording?

      Given those strings, undef will be returned, which sounds perfectly acceptable.

      This sounds reasonable, and I will retract the comment that hints that returning undef might be undesirable. The problem is that tachyon's function does not always return undef on bad input, on the contrary, it can return quite interresting stuff, as my example has shown. I must admit that my example is a bit contrieved, but the OP did not supply any code to analyze. It's an illustration of what can be done.

      It should also return undef when validation fails, but it doesn't.

      You're right.

      While this function returning a number in 0..99 doesn't sound dangerous

      It's not too dangerous, in the sense that it's not an exploit that could make your computer run arbitrary code. It's dangerous in the sense that an attacker could infuse into a computation data gathered from an important variable which he should not have access to. Whether this is dangerous for your particular program or setting, you be the judge. For me it's dangerous enough to be concerned.

      After all, the user isn't providing the regexp

      Take a look at the code in my first reply - it contains a lot of leaning toothpicks and IS valid input to be fed to eval according to tachyon's m!^[\-\+\d\./ \t]+$!.

      My point was that an untrusted user should not be allowed to inject regexps in your runtime, as a matter of principle. Yes, the regexps are from a limited set, but still an infinite set. There might be bugs or corner cases. It's just conservative security practice.