[Asterisk-bugs] [Asterisk 0010167]: Possible injection attack in dialplan - time consuming to program around.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10167 
====================================================================== 
Reported By:                bcnit
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10167
Category:                   PBX/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.6 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             07-10-2007 03:14 CDT
Last Modified:              07-10-2007 07:11 CDT
====================================================================== 
Summary:                    Possible injection attack in dialplan - time
consuming to program around.
Description: 

Because wildcard pattern matching in the dial plan (with the '.'
character) matches against any character, it is not easy to ensure that an
extension (or caller ID) is entirely numeric. If it is not entirely
numeric, then it is not easy to ensure that it doesn't contain any dodgy
characters which may then be used to injection attack the shell (System())
or database (MySQL()).

For example, assume the following (grossly oversimplified) dialplan:

[process-number]
; A simple subroutine which lets us log whatever is passed to us
exten => _X.,1,NoOp(Logging ${EXTEN})
exten => _X.,n,System(/etc/asterisk/bin/simplelogger ${EXTEN})
exten => _X.,n,NoOp(done logging)
exten => _X.,n,NoOp(do whatever else needs to be done.........)


Now, if we issue a:
  Goto(process-number,${CALLERID(number)},1)
We may expect it to work OK.
However, if ${CALLERID(number)} contains "0\;rm -rf /\;#", we're in big
trouble.

OK, so that's the idiot's way of doing things and all the variables should
be checked before we do anything with them.

Unfortunately, there's no easy way to perform these checks.

A large portion of these potential problems could be solved if there was a
wildcard pattern matching character which matched only numbers.

So, if we assume the '%' character is used as a numeric only wildcard, we
could change the code above to:

[process-number]
; A simple subroutine which lets us log whatever is passed to us
exten => _X%,1,NoOp(Logging ${EXTEN})
exten => _X%,n,System(/etc/asterisk/bin/simplelogger ${EXTEN})
exten => _X%,n,NoOp(done logging)
exten => _X%,n(donotlog),NoOp(do whatever else needs to be done.........)
exten => i,1,Goto(donotlog)

Which is nice and simple and also safe.

I appreciate that the example above is very simple, but it does illustrate
the point. Unfortunately, all the checking MUST take place in Asterisk (we
can't trust the call to the external application if it isn't) and Asterisk
doesn't provide the means to do this (easily).

====================================================================== 

---------------------------------------------------------------------- 
 HarryR - 07-10-07 07:11  
---------------------------------------------------------------------- 
Iirc, the ${EXTEN} part is passed raw to the regex function, and the
function then expands that when calling one of the parsing argument
macros.

So if you had:

${EXTEN} = '  ) die asterisk die'

The REGEX command won't be called as 'REGEX("regex" "  ) die asterisk
die', it will be passed correctly to the function which will then have '  )
die asterisk die' as the value to match against. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-10-07 07:11  HarryR         Note Added: 0067040                          
======================================================================