[Starlingx-discuss] Banned C-Functions

[Chris Friesen]

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