[PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning

[Gedare Bloom]

On Thu, Sep 17, 2020 at 1:07 PM Gedare Bloom <gedare at rtems.org> wrote:
>
> On Wed, Sep 16, 2020 at 7:15 PM Chris Johns <chrisj at rtems.org> wrote:
> >
> > On 17/9/20 9:50 am, Joel Sherrill wrote:
> > > On Wed, Sep 16, 2020, 6:43 PM Chris Johns <chrisj at rtems.org
> > > <mailto:chrisj at rtems.org>> wrote:
> > >
> > >     On 16/9/20 11:42 pm, Joel Sherrill wrote:
> > >     > snprintf() is a safe method and I strongly disagree with the blanket
> > >     replacement
> > >     > of many safe methods with memcpy().
> > >     >
> > >     > Based on what POSIX profiles snprintf() is included in and the safety and
> > >     > security requirements those profiles are designed to meet, snprintf() is
> > >     > supported by RTOSes that can meet DO-178 Level A.
> > >     >
> > >     > If the POSIX method being reviewed is in the FACE Safety Base or Safety
> > >     Extended
> > >     > profile, then it is OK to use and has been used in flight qualified
> > >     > applications. And that is a general statement meaning running on any of a
> > >     > variety of RTOSes. If the usage is incorrect, let's fix it but blanket
> > >     changing
> > >     > them is wrong.
> > >
> > >     This is really good information, thank you.
> > >
> > > No problem. That doesn't mean you can't do something stupid with it but
> > > sprintf() would be discouraged and isn't in those profiles as I recall.
> > >
> > >     I see EPICS is reporting similar issues at the moment and looking to work around
> > >     them.
> > >
> > > And no one is questioning why? What's the risk?
> > >
> > >     Is there a history of why this has been added to compilers as a warning?
> > >
> > > I have no idea..snprintf has a length and avoids overwrites.
> > >
> > > I would suggest that we find a safety or security coding standard that warns
> > > about whatever methods this catches.
> > >
> > > Personally replacing snprintf and strong operations with memmove is semantically
> > > wrong.
> >
> > I found this....
> >
> > https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/
> >
> > The "Handling Truncation When It Occurs" section in the blog post is something
> > worth considering. It seems the return value of call should be checked. That
> > seems reasonable.
> >
>
> Nice. *printf also suffer from other security-relevant vulnerabilities
> such as the format-string attack:
> https://owasp.org/www-community/attacks/Format_string_attack
>
> This means replacing their use with alternatives can be generally more secure.
>

Also, if the format string is unnecessary, then using *printf is
adding a lot of overhead vs a mem*() call.

> > Chris
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel