<p>One more thing that just came to mind;<br>
Shouldn't alwaysauthreject be considered to be enabled by default for the same reason?</p>
<p>My apologies if that is already the case.</p>
<p>Regards,<br>
Örn</p>
<div class="gmail_quote">On Oct 21, 2011 11:24 PM, "Örn Arnarson" <<a href="mailto:orn@arnarson.net">orn@arnarson.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I don't really have anything to add except from superficially -- just<br>
wanted to toss in my vote for which option to deal with this problem<br>
sounds the most appealing.<br>
<br>
In my opinion, option #3 sounds like a clear winner. From what I can<br>
tell from the historical background you wrote (which was a very<br>
interesting read, by the way), it seems like it should've been made<br>
the default behavior a long time ago anyway.<br>
<br>
Option #1 sounds like a really hard sell. Using UDP for SIP is such a<br>
norm that I can't remember encountering anyone who uses TCP apart from<br>
Microsoft Lync/OCS. Not to say that it's a bad idea at all, but once<br>
something has become a de-facto industry standard, it's hard to shift.<br>
I think this option would probably lead to most people ignoring the<br>
security issue.<br>
<br>
Option #2 also sounds like a hard one. If we assume that there will be<br>
some devices where this change will break their interoperability over<br>
certain NAT scenarios, it would be a cause of significant problems for<br>
people who I'm sure would much rather solve their security issues via<br>
firewalling or just ignoring them altogether. Additional security<br>
measures can be taken by most admins. Changing the code and<br>
re-compiling, or even getting the UA fixed by the manufacturer is a<br>
much harder task (or it may seem so to the person who has to perform<br>
it at least).<br>
<br>
Having the option to disable nat, and perhaps explaining the<br>
ramifications with comments above the sample entry, seems like the way<br>
to go to me. More versatility and more freedom for the user. Assuming<br>
that he knows what he's doing isn't such a bad thing, I think.<br>
Additionally, I think having to disable something rather than enable<br>
is more likely to make you think about what it is you're disabling as<br>
well, so maybe it's enough. Especially if you do it in [general].<br>
Maybe that's just me though.<br>
<br>
Now, as to whether or nat=yes is always set on *my* definitions, then<br>
the answer is no. Why? Because I never bothered to actually check<br>
whether what nat=yes did was something that was desireable for all<br>
clients or not. All I knew was that if I had problems with NATed<br>
clients, this would usually fix it. I assumed nat=yes meant breaking<br>
some RFC behavior to try to satisfy shitty ALGs. Furthermore, as it<br>
isn't enabled by default I thought it could possibly have some<br>
detrimental effect on non-NATed UAs. I think maybe the name is a bit<br>
misleading.<br>
<br>
Anyway, sorry if this isn't helpful or relevant at all, but it seemed<br>
like you were basically asking for feedback from anyone with an<br>
opinion in the matter.<br>
<br>
Regards,<br>
Örn Arnarson<br>
<br>
On Fri, Oct 21, 2011 at 10:52 PM, Kevin P. Fleming <<a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a>> wrote:<br>
> Sorry in advance for the length of this message... I've intentionally<br>
> included quite a lot of background information so that we can hopefully be<br>
> able to discuss this issue rapidly and reach consensus.<br>
><br>
> Recently, a potential security issue was brought to our attention: it has<br>
> existed in (probably) every version of Asterisk that included chan_sip. It's<br>
> not something we'd classify as 'critical' or even 'major', but it is a<br>
> concern we want to address. Terry Wilson has spent some time investigating<br>
> it, and then he and I spent some time over the last couple of days thinking<br>
> about how (or if) it can be addressed.<br>
><br>
> The essence of the problem is this: it is possible under some circumstances<br>
> for an attacker to be able to enumerate (discover) the names of SIP peers<br>
> (and possibly users) defined on an Asterisk system. If they can discover the<br>
> valid peer names, they can then focus password-guessing attacks on those<br>
> names, which increases their chances of being able to gain access to the<br>
> system. Generally speaking we've tried to make changes to Asterisk to remove<br>
> this type of 'information disclosure' vulnerability, in order to help<br>
> Asterisk users keep their systems as secure as possible.<br>
><br>
> Unfortunately in this case, we can't solve the problem without removing a<br>
> useful feature of chan_sip. Here's why:<br>
><br>
> According to RFC 3261, when Asterisk (acting as UAS) receives a SIP request<br>
> from another SIP entity (acting as UAC), any responses that Asterisk<br>
> generates must be sent back to the IP address that the request was received<br>
> from, but to the *port number* specified in the top-most Via header included<br>
> in the request (this is important: they are *NOT* sent back to the port<br>
> number the request was received from).<br>
><br>
> For most SIP clients, who are not sending their SIP requests across NAT<br>
> devices, this is not a problem; they'll send their requests from port 5060,<br>
> and expect responses on port 5060 (and they'll either explicitly specify<br>
> port 5060 in that top-most Via header, or they'll leave it out and let the<br>
> RFC-specified default take effect). There could be some SIP clients out<br>
> there who send their requests from one port (port A), but want to receive<br>
> responses on a different port (port B). In this case, the top-most Via<br>
> header will include port B, not port A. In our experience, this is extremely<br>
> uncommon, but it is RFC compliant behavior.<br>
><br>
> When NAT devices enter the picture, though, things get more complicated (as<br>
> they always do). Going back to the 'normal' SIP clients, that send requests<br>
> from, and expect responses on, the same port... now they have a problem. If<br>
> they send their request from port 5060, and expect responses on 5060, their<br>
> top-most Via header will reflect that. However, when the request crosses the<br>
> NAT on its way to the UAS, it will appear to have been sent from a different<br>
> IP address and port number than the UAC sent it from (by definition...<br>
> network address translation). Asterisk (the UAS) will respond back to the IP<br>
> address that the NAT used to send the request, but it will *NOT* respond to<br>
> the port number the NAT assigned; it will respond to the port number in the<br>
> top-most Via header. Unless the NAT device just happened to assign the same<br>
> port number (and some NAT devices will attempt to do that), or if the NAT<br>
> administrator has setup a static mapping for that port number, the response<br>
> will be lost... it will arrive at the NAT device, it won't match the port<br>
> mapping established when the request passed through, and the NAT device<br>
> won't forward it.<br>
><br>
> This dilemma was identified long ago (over 8 years), and an additional RFC<br>
> was published: RFC 3581. This RFC allows the 'rport' parameter to be added<br>
> to Via headers; this allows UACs who are aware that their requests may be<br>
> crossing a NAT device (or even if they aren't aware, but just want to be as<br>
> safe as possible) to indicate to the UAS that receives their request that<br>
> the UAS should respond to the port that the request was received from, *NOT*<br>
> the port listed in the top-most Via header. Some people would say that this<br>
> is how SIP should have worked from the beginning, and that the extraction of<br>
> *only* the port from the top-most Via header never made any sense at all (I<br>
> would personally agree with those people), but history is what it is. In<br>
> addition to this behavior change, the 'rport' parameter also indicates that<br>
> the UAS should report back to the UAC the 'perceived' port number; this is<br>
> useful, but is not part of the problem being discussed here.<br>
><br>
> Asterisk supports RFC 3581, and if a UAC includes 'rport' in its top-most<br>
> Via header, Asterisk will indeed respond to both the IP address *and* port<br>
> number that the request was received from.<br>
><br>
> However (and here's where we run into trouble), there are some (maybe many)<br>
> SIP UAs out there that cannot (or just do not) include 'rport' in the<br>
> top-most Via headers of their requests. Because of this, these UAs can be<br>
> difficult to use behind a NAT device (unless the NAT is configured specially<br>
> as outlined above), because Asterisk can't deliver responses to the UA (port<br>
> number mismatch). In order to make these devices 'work', Asterisk gained a<br>
> 'nat' configuration option many, many years ago that, if set to 'yes' (it<br>
> defaults to 'no') tells chan_sip to act *AS IF* the UAC had included 'rport'<br>
> in its top-most Via header, even if it didn't. This does in fact solve the<br>
> problem; responses can now be delivered to the UAC, and the fact that<br>
> Asterisk adds 'rport' to the Via header in the response is not harmful...<br>
> the UAC just ignores it.<br>
><br>
> In later versions of Asterisk this configuration option gained some<br>
> additional behavior (enabling 'connection-oriented media' mode), but again,<br>
> that's not part of this issue. In recent versions, the value of this option<br>
> can even be specified as 'force_rport' to more clearly indicate the desired<br>
> behavior.<br>
><br>
> Now we get to the crux of the problem: this 'nat' option can be set both at<br>
> the '[general]' level in sip.conf, and also for peers. This means, of<br>
> course, that they values can differ (and frequently they will, but not<br>
> because the administrator intended for them to differ). This means there are<br>
> four possible combinations, with possible different behaviors. For the<br>
> purposes of this discussion, let's assume that a UAC is sending a request<br>
> (the request type does not matter) that does *NOT* include 'rport' in its<br>
> top-most Via header. In addition, the UAC is purposely sending its request<br>
> from port A, but specifying port B in the top-most Via header. Let's also<br>
> assume there is a peer called 'alice' defined in sip.conf.<br>
><br>
> Scenario 1: [general] nat=no, [alice] nat=no<br>
><br>
> No problem here; the behavior of Asterisk will be the same regardless of<br>
> whether the request matches the 'alice' peer or not.<br>
><br>
> Scenario 2: [general] nat=yes, [alice] nat=yes<br>
><br>
> No problem here; the behavior of Asterisk will be the same regardless of<br>
> whether the request matches the 'alice' peer or not.<br>
><br>
> Scenario 3: [general] nat=no, [alice] nat=yes<br>
><br>
> Problem here; if the request matches 'alice', Asterisk will respond to port<br>
> A. If the request does not match 'alice', Asterisk will respond to port B.<br>
><br>
> Scenario 4: [general] nat=yes, [alice] nat=no<br>
><br>
> Problem here; if the request matches 'alice', Asterisk will respond to port<br>
> B. If the request does not match 'alice', Asterisk will respond to port A.<br>
><br>
> As you can see, in both scenarios 3 and 4, if the attacker happens across a<br>
> peer name (or source IP address) that happens to match a peer defined in<br>
> sip.conf, and that peer's 'nat' setting differs from the general NAT<br>
> setting, the attacker will be able to notice the difference in response<br>
> pattern from when the request did not match any peer.<br>
><br>
> So now we know what the problem is, and what causes it. I'll offer up some<br>
> possible solutions below, and ask for you all to think about this situation<br>
> and help us decide on the right course of action. The eventual goal here is<br>
> to produce a security advisory document telling users about the situation<br>
> and what they can/should do to try to mitigate it; we don't expect that<br>
> there is any solution that will solve the problem for all users.<br>
><br>
> Option 1:<br>
><br>
> Recommend that all users to switch to TCP (or TLS) for SIP communications.<br>
> If they have a version of Asterisk that supports TCP, and devices that also<br>
> support it, they can disable UDP support and avoid this problem entirely<br>
> (since TCP does not have these NAT traversal issues to deal with).<br>
><br>
> Option 2:<br>
><br>
> Change Asterisk to always act in 'force_rport' mode, period<br>
> (non-configurable). It is possible that there may be some SIP UAs that would<br>
> break if Asterisk did not respond to the port listed in the top-most Via<br>
> header, but it seems rather unlikely at this point. Such UAs would almost<br>
> never be able to be used successfully behind a NAT device. In addition, it<br>
> is remotely possible that there are some SIP UAs that will break if they see<br>
> 'rport=<xxxx>' in the Via header returned by Asterisk in its responses.<br>
><br>
> Option 3:<br>
><br>
> Allow 'force_rport' mode to be disabled, but change the default to enable<br>
> it, in all currently maintained branches (1.4, 1.6.2, 1.8, 10 and trunk).<br>
> This has the same caveats as Option 2, but at least if a user *does* have<br>
> one of these bizarre SIP UAs to deal with, they can set 'nat=no' for that<br>
> device after carefully considering the ramifications of the change.<br>
><br>
> There may be other options to consider, but Terry and I were unable to come<br>
> up with any.<br>
><br>
> So, questions for the assembled audience here:<br>
><br>
> Do you have any other options for us to consider?<br>
><br>
> Are you aware of any SIP UAs that actually *REQUIRE* "nat=no" to<br>
> interoperate with Asterisk?<br>
><br>
> Do you *always* set "nat=yes" on your SIP peer definitions? Do you also set<br>
> "nat=yes" in the '[general]' section? If not, why not?<br>
><br>
> --<br>
> Kevin P. Fleming<br>
> Digium, Inc. | Director of Software Technologies<br>
> Jabber: <a href="mailto:kfleming@digium.com">kfleming@digium.com</a> | SIP: <a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a> | Skype: kpfleming<br>
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
> Check us out at <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
><br>
> --<br>
> _____________________________________________________________________<br>
> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
><br>
> asterisk-dev mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
><br>
</blockquote></div>