mainGnuTLS - Support: sr #107522, Use of dangerous/banned functions

 
 

sr #107522: Use of dangerous/banned functions

Submitter:  Jeffrey Walton <noloader>
Submitted:  Tue 16 Nov 2010 11:30:10 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 18 Nov 2010 03:21:44 AM UTC, comment #6: 

Hi Simon,

This statement needs a little more elaboration:

> So the policy [which I prefer] is "secure, robust, efficient, and portable code."


== Secure ==

Here's the signature for a secure strcpy (less restricted pointers). Obviously, the const on the pointers can be dropped but I prefer them until otherwise.

Many folks don't care for it (especially if the function asserts), but if fully specifies all parameters. It returns success, bad parameter, or truncation.

errno_t safe_str_copy(char* const pDest, size_t nDest,
    const char* const pSrc, size_t nSrc, size_t nCount);

== Robust ==

For "robust", the project will have to determine what to do. I personally think perror/exit is the least desired combination. But sometimes its all you have.

== Efficient ==
Make one pass, do things in less than (or equal to) O(n), and turn to the native ASM memcpy (which should already be done).

== Portable ==
Use wrappers and (a) strcpy_s or StringCbCopy on Microsoft (b) strlcpy on BSD and Solaris, and (c) memcpy on GNU systems.

Jeff

Jeffrey Walton <noloader>
Wed 17 Nov 2010 11:18:51 PM UTC, comment #5: 

Hi Simon,

I'm going to field things out of order to improve the flow of responses.

> The strlcpy etc are as criticized as the strcpy functions...

I have also read the counter arguments, which I am going to paraphrase below. The arguments are generic, and not specific to strcpy_s (and friends) or strlcpy (and friends). Please feel free to correct or expand my compilation below.

: There are two major issues with using the safer
: string functions:
: (1) The replacement functions do not completely solve the
: "unsafe" handling inherent in the original functions.
: (2) The replacement functions are slower than the original
: functions under some circumstances and implementations.

To re-frame the arguments above, consider: you are a junior programmer making $20 hour (an unsafe function). You want to be a project manager making $60 hour (a safe, efficient, replacement function). Sometime in your career, you are offered a senior programming position at $40 hour (a safer function). But you reject the offer since its not the position of program manager.

== Item 1 ==
Does it make sense to reject the $40 hour position? Does it make sense to reject the safer functions because they were only designed to be a [near] drop in replacement to help remediate issues in the existing code base?

I believe the syndrome is colloquially referred to as, "throwing the baby out with the bath water".

== Item 2 ==
The B programming language made its debut circa 1969. C followed from B in the 1970s. strcpy and friends made their debut nearly 40 years ago!

Unfortunately, it took less than 40 years for the environment, which was originally benign, to turn hostile or toxic. The Dataloss Database (http://datalossdb.org/) is testament to the fact.

"They who can give up essential security to obtain a little temporary speed, deserve neither security nor speed."
- Benjamin Franklin, circa 1775

== Item 3 ==
Item 3 did not make the list, but it always plays a role in matters such as these: political feasibility.

Microsoft sponsored the initiative at ISO/IEC. The "initiative" was "Extensions to the C Library Part I: Bounds-checking interfaces". This is also known as "safer string handling functions". It is now a normative part of the current C1X draft (latest version dated 2010-10-04).

The initiative was accepted and originally presented as a Type 2 Technical Report, which means "there is the future but not immediate possibility of an agreement on an International Standard".

The take away: Item 3 is "sour grapes".

> ...decisions within gnulib to not provide portability
> wrappers for them because it is not a good idea

This effect is "no support for safer functions". It is directly attributed to (1) above.

In this case, what are the distributions, POSIX, or the Open Standards group, et al offering for the complete resolution of the problems and issues associated with the original [unsafe] functions? That is, what are the "safe" functions (not "safer" functions)?

For portability via standardization, I'm willing to use a set of wrappers which [the wrappers] call into safer functions.

> Do you have some concrete pointer to broken GnuTLS code?

Ah!!! It's not about a single instance of broken code. I don't want to fix 1 stack smash, or 1 buffer overflow for that matter. A particular stack smash or buffer over flow is irrelevant in the big picture.

I want policies - which are transformed into procedures - that ensure all stack smashes, buffer overflows, and other miscreants go the way of the dinosaurs.

So the policy [which I prefer] is "secure, robust, efficient, and portable code." One of the ways to make it happen is via a policy which requires all project code to call through a wrapper, and then the wrapper calls a safer function.

To summarize, it is about learning from the past, and moving forward in a safe, robust, and efficient manner. Portability is icing on the cake.

Allow of this is technically feasible. Some of it is politically infeasible.

Jeff

Jeffrey Walton <noloader>
Wed 17 Nov 2010 02:34:04 PM UTC, comment #4: 

Do you have some concrete pointer to broken GnuTLS code?  It would help to make this discussion a bit more down to earth.

The strlcpy etc are as criticized as the strcpy functions, and I recall decisions within gnulib to not provide portability wrappers for them because it is not a good idea.

/Simon

Simon Josefsson <jas>
Group administrator
Wed 17 Nov 2010 03:52:30 AM UTC, comment #3: 

Attaching "Secure Portability" by Damien Miller. Miller lists systems which include support for safer string handling functions such as strl* and friends.

Bounds-checking interfaces are now included in the C1X draft dated 2010-10-04 (previously included via TR 24731-1, which was included in Annex K of an earlier C1X draft). A link to the C1X draft (ISO/IEC 9899:201x) can be found at http://www.open-std.org/Jtc1/sc22/wg14/www/projects. Grab the PDF for N1516.

Links to TR 24731-1 (Extensions to the C Library Part I: Bounds-checking interfaces) and TR 24731-2 (Extensions to the C Library - Part II: Dynamic allocation functions) can be found at http://www.open-std.org/Jtc1/sc22/wg14/www/projects. Grab the PDFs for N1225 and N1337.

The take away is that strlcpy and friends are almost ubiquitous on *nix, and strcpy_s and friends will be standardized shortly.

Jeffrey Walton <noloader>
Wed 17 Nov 2010 12:49:41 AM UTC, comment #2: 

It occurred to me: use of unsafe functions are still at pandemic proportions, yet I don't recall ever seeing a GCC warning.

Doing something about it: "Request: Warning for use of unsafe string handling functions", http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513.

Mircosoft's tool chain emits warnings on their use, and SAL (/analyze) takes its a step further by offering abuse scenarios (for example, "readable size is 4 bytes, but 16 bytes might be read").

Jeffrey Walton <noloader>
Wed 17 Nov 2010 12:09:00 AM UTC, comment #1: 

Forgot to mention....

I cited Apple's security guide because the table is compiled (so it offers copy/paste convenience). Wheeler's security guide says about the same in more words (Wheeler is more in depth because he also discusses other "safe" libraries). And Microsoft has a succinct page: Security Development Lifecycle (SDL) Banned Function Calls, http://msdn.microsoft.com/en-us/library/bb288454.aspx.

One fellow on [BuqTraq|FunSec|FullDisclosure] summed it up nicely, "there's no reason to be using strcpy in 2010". (can't find the reference at the moment).

Jeffrey Walton <noloader>
Tue 16 Nov 2010 11:30:10 PM UTC, original submission:  

GnuTLS uses unsafe string handling functions. From Apples Security Guide, Table 1 (p. 35):

Table 1: String functions to use and avoid
Don't use these functions - Use these instead
--------------------------+--------------------------
strcat                    | strlcat
strcpy                    | strlcpy
strncat                   | strlcat
strncpy                   | strlcpy
sprintf                   | snprintf
vsprintf                  | vsnprint


The same theme rings true in the Microsoft world. For example, see Howard and LeBlanc's Writing Secure Code. Use of safe string handling functions is a secure code quality gate. Microsoft software which uses dangerous and banned functions will not pass internal quality checks.

References

Apple Inc., "Secure Coding Guide: Security", String Handling, p.35.
Wheeler, "Secure Programming for Linux and Unix HOWTO", Section 6.1 Dangers in C/C++, p 61.

Jeffrey Walton <noloader>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Updated the item)
  • -email is unavailable- added by jas (Posted a comment)
  • -email is unavailable- added by noloader (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-04-10 nmav Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code