perfSONAR User Q&A and Other Discussion

[Simon Leinen <>]

Frederic LOUI writes:
> I don't know whether you're already aware of that security
> vulnerability, but could the developer's team of the PerfSONAR
> TELNET/SSH MP take into account this security issue ?
> (and forbid the use of regular expressions ? ==> Other suggestions
> are welcomed)

In contrast to your and Janos' suggestion, we chose NOT to address
this issue by forbidding regular expressions entirely.  Rather, our
looking glass[1] now filters query arguments against a "whitelist"
regexp which currently only tests for a set of valid characters.
Here's the code I inserted into Havard Eidnes' looking glass script:

    if (defined $arg and ! ($arg =~ 
m@^([-/a-z0-9\
 
_|().]*)$@imx))
 {
        $results[0] = "Illegal characters in argument string\n";
        &print_results("");
    } else {
        $arg = $1;              # Lose additional lines
    }

You will notice that regexps including ( | ) _ are still supported,
but neither the asterisk (*) nor the backslash (\) are.  As far as I
know, the router-crashing regexps have to include both of these.

The rationale is that there are useful queries that can currently only
be expressed using regexps.  Here's an example of someone asking a
totally reasonable question[2] on a regional ISP mailing list:

  Subject: [swinog] Customers of Telia AS1299 around ?

  Could you check if you see any prefix  on this path ? ^1299_15600
  Thanks

With our looking glass, they can look this up themselves in a few
steps (find which of our routers has the peering with AS1299, find the
AS1299 peer's IPv4 address using "bgp summary", and then issuing the
"bgp" command with the argument string

  "neighbor <peer-address> received-routes | i _1299_15600_"

Since it is pretty much impossible to define the complete set of
reasonable queries a priori, I'm unwilling to disable more
functionality than necessary.

We can always make the network more secure by disabling functionality,
but we'd also make it less useful (in this case, harder to debug and
thus less robust).  The hard part is to find the right balance.

In the case of the Looking Glass, I personally think these could be
made both more useful and more secure, by moving to higher-level
operations that don't necessarily map directly to router CLI
(Command-Line Interface) commands.  In addition, limits against
resource exhaustion "attacks" would be useful.  (I use quotes because
those may happen accidently, think of someone saying "show ip bgp"
without an argument when they wanted to say "show ip bgp summary".)

This is even more valid for a general CLI proxy such as the Telnet/SSH
MP.  The ideal evolution of this would be a higher-level service that
would allow access to a well-known set of useful (monitoring)
operations, in a form that's independent of the actual CLI syntax.

Preferably that format would have lots of angle brackets and is
formally defined using some kind of schema...
-- 
Simon.
[1] http://www.switch.ch/network/tools/lookingglass/
[2] http://lists.swinog.ch/public/swinog/2007-September/002099.html