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

noreply at bugs.digium.com noreply at bugs.digium.com
Tue Jul 10 07:17:03 CDT 2007


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:17 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).

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

---------------------------------------------------------------------- 
 bcnit - 07-10-07 07:17  
---------------------------------------------------------------------- 
OK. Thank you.

If it is the case that the REGEX() function is bulletproof, then can I
request that this bug is downgraded to a feature request?

I still think it would be useful to be able to wildcard-match numbers
only. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-10-07 07:17  bcnit          Note Added: 0067041                          
======================================================================




More information about the Asterisk-bugs mailing list