Summary:	ASTERISK-06993: Malicious (or dumb) user forwarding their own extension to their phone.
Reporter:	William Clayton (wclayton)	Labels:
Date Opened:	2006-05-17 17:29:50	Date Closed:	2006-05-18 02:32:06
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Say I am at extension 2010 and I set my phone to forward incoming calls to extension 2010. I then proceed to go to sleep whilst callers await my assistance in the queue and when it becomes my turn to answer Asterisk ends up in a loop that will spawn a jillion processes and crash Asterisk if not the server. To make matters worse, if I forward the call to a cell phone, and then forward those cell phone calls back to your system, by the time the call is answered by the cell phone and redirected, Asterisk seems to have a very bad short term memory, and as a result the loop is truly endless because of the delay involved. I know about this because I used to work at a call center in high school and now I have to deal with it. Talk about karma. ****** ADDITIONAL INFORMATION ****** Funny. I know. Its been suggested that I write a huge macro to overcome this. But on every system? This does not seem practical in any sense, and this is a real issue that can cause downtime. I can't see any sense in designing a system AROUND this when it can be fixed in the c (dont ask me how, yet). I realize the phone should not be allowed to do this, but unfortunately contacting every vendor of every phone I'll ever have to use would most likely be quite futile.
Comments:	By: Joshua C. Colp (jcolp) 2006-05-17 17:41:20 This isn't really possible because in Asterisk an extension is not a phone - as much as people think it is. An extension is a set of instructions that executes applications. Therefore it would be very hard to prevent what you're talking about because the system would need to know ahead of time that this extension belongs to this phone. By: Joshua C. Colp (jcolp) 2006-05-17 19:41:19 Closing this unless you can provide a viable method of protecting against it. I suggest discussing it on the development list if you do. By: William Clayton (wclayton) 2006-05-18 01:46:30 I appreciate your request for the community's input on the matter, however this is a simple DOS attack on any Asterisk system and the importance should not be played down. Any workaround I provide to alleviate the problem will obviously consist of overhauling any given system considering the depth to which one will have to go to ensure that any different caller ID will need a completely new context in extensions.conf. Forgive my crude understanding of the practice but I have had quite a bit of input for the last few months to no avail. Please don't mistake my ambition for ingnorance. I simply would like to see a sensible closure to the problem: Any local user of Asterisk registered as any presence in extensions.conf can perform a Denial of Service attack on an Asterisk system by forwarding their own extension to itself from nearly given device. The result is a loop within the dialing procedure that Asterisk cannot detect and will eventually saturate all available resources to the Asterisk user if not root in some unsecured systems. I propose a jailed implementation of Asterisk in the short term which can be accomplished by a simple chroot'ed environment for that user and subsequent filesystem heirarchy; upon analysis of necessary resources. Since this is not documented or at least well known in the applicable user community (even the Linux community), I urge all those involved to invest time in evaluating the source for possible solutions if not documentation of simple procedures to allocate device and filesystem access to the asterisk user alone. The catch is allowing unpriveleged use of the system to affect it as desired of course. I do understand that this is one of those things that can compromise freedom for security which is why a wide-spread call to arms is needed to address the problem. Do not mistake this for alarmism. Asterisk depends on user input and what we are experiencing to this degree is the threshhold for such. This is a paramount obstacle on which our closed source and anti-consumer competitors, for lack of a better word, will capitalize upon. All it takes is literally seconds of physical access to the facility to disable the entire system IF NOT THE PROVIDER. There are widespread cases where this kind of activiy cannot be controlled or anticipated on Level 2. We have the opportunity to stare down this beast. Ugly as it may sound it is going to take time to fix and effort to approach. I want to help. I just want those in the loop to understand what we are up against. We should fix it while we can. My immediate focus is calling of an external script or executeable from within the dial plan as you suggested, further possibly an extensible class or future module in the case of the latter, (think idiot_check.h). One thing I can ask for is more variables to parse. "This isn't really possible because in Asterisk an extension is not a phone." Of course, but how often in the real use should an extension be allowed to dial iteslf? I honestly cannot think of any instance where it should repeat enough to bring down a system. An extension can belong to a group, a queue, but it should not be allowed to affect itself in any way. In essence this gives anyone with a phone nearly complete control of the system in terms of on or off. By: Tilghman Lesher (tilghman) 2006-05-18 02:32:06 Again, please take this discussion to the -dev list.  This forum does not facilitate active discussion of an issue.