[Starlingx-discuss] Banned C-Functions

[Young, Ken]

Chris,

Thank you for the detailed review.  

I updated the policy for sscanf to allow for core review.  I added scanf / vscanf to this line as well.  I did not add fscanf / vnscanf; these functions are not on the banned c-list from Microsoft (https://msdn.microsoft.com/en-us/library/bb288454.aspx).

I also updated to strncat to inspect for buffer overflow as well.

Regarding the remaining function mentioned, these are not covered on the Microsoft banned c list.  If there are issues with these functions, perhaps we can create a coding guide.

Regards,
Ken Y

On 2018-12-17, 1:22 PM, "Chris Friesen" <chris.friesen at windriver.com> wrote:

    On 12/17/2018 9:19 AM, Young, Ken wrote:
    > All,
    > 
    > As was discussed on the community call, the Starling X security team has 
    > been working on a banned c-function policy to help avoid the 
    > introduction of security vulnerabilities.  Up to now, this policy has 
    > been a draft.  We have resolved all outstanding issues with the policy 
    > and we are currently looking for community feedback on the policy before 
    > asking the cores to enact the policy.  It can be found here:
    > 
    > _https://wiki.openstack.org/wiki/StarlingX/Security/Banned_C_Functions___
    > 
    > The goal is to gather and resolve any community issues by January 9^th 
    > .  These can be discussed either on the mailing list or in the community 
    > meetings on Wednesday, 10 AM EDT.  After this point, the ask would be 
    > for the cores to ensure that no /new/ instances of banned functions are 
    > added to the code.
    
    The "sscanf" one doesn't suggest what to use instead.
    
    Also, "sscanf" is not necessarily unbounded, it allows the caller to 
    specify field widths, but they're optional.  So it might make sense to 
    allow with approval from core.  The other problem with all the "scanf" 
    family is that the arithmatic conversions don't protect against 
    arithmatic overflow, so the "strto*" type functions are more robust for 
    use with unknown inputs.
    
    What about scanf, fscanf, vscanf, vsscanf?
    
    What about tmpfile() and mktemp() which are safe to use but can easily 
    introduce security issues?  (Should use mkstemp() instead.)
    
    What about gethostbyaddr() and gethostbyname() which are non-reentrant 
    and don't support IPv6 well?  (Replaced by getaddrinfo() and 
    freeaddrinfo().)
    
    strncat() should also be inspected for overflow.  A call to "strncat(s1, 
    s2, n) can end up writing strlen(s1)+n+1 characters to the buffer.
    
    setjmp()/longjmp() should be reviewed *extremely* carefully, especially 
    if combined with threaded code.
    
    system() should be used very cautiously
    
    Chris
    
    _______________________________________________
    Starlingx-discuss mailing list
    Starlingx-discuss at lists.starlingx.io
    http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss