| Summary: | ASTERISK-24133: [patch]Please support Clang; Allow no-exec stacks | ||||
| Reporter: | Jeffrey Walton (noloader@gmail.com) | Labels: | |||
| Date Opened: | 2014-07-30 10:14:41 | Date Closed: | 2014-08-07 13:53:59 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Core/BuildSystem | ||
| Versions: | 12.4.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Linux and OS X | Attachments: | |||
| Description: | Please support Clang. Clang is a useful compiler because (1) its the preferred or default compiler on some platforms (for example, OS X); (2) it allows additional static analysis (compile time); and (3) it provides dynamic analysis (runtime) by way of its sanitizers.
Configuring with Clang results in compile failures. For example: export CC=clang export CXX=clang++ ./configure There appears to be two broad issues. First, Clang does not support GCC's nested functions. Nested functions are a problem for both portability and security. The compile errors speak to the portability issues. Loss of no-exec stacks is the security issue. The loss of no-exec stacks is probably a security related defect. Its not clear to me if Asterisk has a SDLC, so this is being file as an Improvement rather than a Bug. The first issue already has a solution at https://reviewboard.asterisk.org/r/3488/. The second issue is multiply defined symbols. The multiply defined symbols issue has existed for years. After spending a couple of days (on and off) searching for a solution, I have not found one. For a brief history, see [1,2,3,4]. [1] ASTERISK-21720 [2] http://clang.debian.net/status.php?version=3.3&key=MULTIPLE_DEF [3] http://lists.digium.com/pipermail/asterisk-users/2011-June/263933.html [4] http://asteriskfaqs.org/tag/information/page/6 | ||||
| Comments: | By: Rusty Newton (rnewton) 2014-08-06 17:45:36.200-0500 {quote} The first issue already has a solution at https://reviewboard.asterisk.org/r/3488/. The second issue is multiply defined symbols. The multiply defined symbols issue has existed for years. After spending a couple of days (on and off) searching for a solution, I have not found one. For a brief history, see {quote} You probably want to split the second issue out into another JIRA issue to be tracked separately. We'll consider this issue to relate to your first mentioned issue with a reviewboard link. By: Matt Jordan (mjordan) 2014-08-07 13:53:12.048-0500 Just for the record: {quote} The loss of no-exec stacks is probably a security related defect. Its not clear to me if Asterisk has a SDLC, so this is being file as an Improvement rather than a Bug. {quote} I disagree with this. First, I'm assuming by SLDC you're referring to a "Secure Software Development Life Cycle". As an open source project, Asterisk as a project does not mandate any particular software development methodology. Developers are free to use whatever software development methodology that ascribe to in their respective development processes. The project does maintain a set of agreed upon rules that determine the following: # How patches are submitted to the project # What patches are appropriate for which branches # The lifecycle of the various release branches All of that information is available on the wiki. From the perspective of security, the project takes a very serious approach to actual vulnerabilities. The fact that a particular security provision is not available is not a vulnerability. It only means that some mechanism for protecting the project against certain attack vectors is not available; that does not impact the presence of those vectors, nor does it make Asterisk more susceptible to those attacks. It merely removes one mechanism for those attacks - if they exist - to succeed. Flipping this around: the inclusion of RAII_VAR - which depends on gcc's nested functions - has substantially eliminated channel reference leaks, memory leaks, and a whole host of other issues that *can* be exploited to exhaust resources. While one may claim that using nested functions - by precluding no-exec stacks - is a security issue, the fact that their usage has eliminated a whole class of actual, exploitable issues more than supersedes a theoretical use case. This is not a security vulnerability, nor a security issue. It was an intentional design decision. I fully understand that there may be many (including the reporter) who disagrees with this. This is an open source project, patches are welcome. To the patch at hand: The major issue with this patch is its lack of testing and verification. If the community (and the reporter) are willing to verify the functionality continues to work appropriately when compiled using gcc as well as clang, then that would be great. It would certainly be nice to have Asterisk be compiled using more than just gcc. All of that being said, that issue is already open. As this is a duplicate of that issue, this issue will be closed out as a duplicate. Testing and validation of that patch should happen on the original issue. | ||||