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@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@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss