Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 338163 - net-misc/miniupnpd _FORTIFY_SOURCE indicates presence of overflow
Summary: net-misc/miniupnpd _FORTIFY_SOURCE indicates presence of overflow
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Bjarke Istrup Pedersen (RETIRED)
Depends on:
Blocks: fortify-source
  Show dependency tree
Reported: 2010-09-20 11:35 UTC by Diego Elio Pettenò (RETIRED)
Modified: 2011-01-18 21:37 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

Build log (miniupnpd-1.5_pre20091222:20100919-030625.log,10.46 KB, text/plain)
2010-09-20 11:36 UTC, Diego Elio Pettenò (RETIRED)
Patch to miniupnpd-1.5_pre20091222.ebuild to address numerous issues (miniupnpd-1.5_pre20091222.ebuild.patch,1.08 KB, patch)
2010-09-21 04:14 UTC, Kevin Pyle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Elio Pettenò (RETIRED) gentoo-dev 2010-09-20 11:35:51 UTC
You're receiving this bug because the package in Summary has produced _FORTIFY_SOURCE related warnings indicating the presence of a sure overflow in a static buffer.

Even though this is not always an indication of a security problem it might even be. So please check this out ASAP.

By the way, _FORTIFY_SOURCE is disabled when you disable optimisation, so don't try finding out the cause using -O0.

Your friendly neighborhood tinderboxer
Comment 1 Diego Elio Pettenò (RETIRED) gentoo-dev 2010-09-20 11:36:07 UTC
Created attachment 248127 [details]
Build log
Comment 2 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2010-09-20 11:44:14 UTC
Hey :-)

Why doesn't this get reported directly to upstream as portage states it should?

 * Please do not file a Gentoo bug and instead report the above QA
 * issues directly to the upstream developers of this software.
 * Homepage:

I'm not that much into this problem, so I'm not totally sure on how to explain it to upstream anyway.
Could I get you to take it upstream?
Comment 3 Diego Elio Pettenò (RETIRED) gentoo-dev 2010-09-20 11:50:04 UTC

… no it's not something we should be simply ignoring and wait for upstream; and I cannot bring all of them upstream; if you really can't seem to find the problem after looking into it I'll try to make some time to look into it, but there are just too many things on my plate already…
Comment 4 Xake 2010-09-20 12:20:46 UTC
(In reply to comment #2)
>  * Please do not file a Gentoo bug and instead report the above QA

Is not this reasoning flawed as this is a bug that maybe should be considered when it is stabilization-time, and if there is no bugs open in Gentoo-bugzilla, how do you track them?
Comment 5 Kevin Pyle 2010-09-20 15:16:13 UTC
(In reply to comment #2)
> Why doesn't this get reported directly to upstream as portage states it should?

Some upstream providers have been very reluctant to recognize or act upon bugs reported based solely on static analysis, even for cases like this where (barring a bug in the static analyzer code), the upstream code is clearly wrong.  I have no idea whether this _particular_ upstream is reluctant to act.  This is just a comment on why it has become standard practice for Tinderbox bugs to come to Gentoo bugzilla first.

I suspect the phrasing of that message is a remnant from when it warned about code which was questionable, but not guaranteed to fail.  In particular, implicit declarations are considered poor practice, but may work fine _if_ the author did everything else right.  Warnings about "will always overflow destination buffer" are an indication of a real bug in every case, and can in some cases be a security issue for people who build without fortification.

Diego is set up to report Tinderbox-discovered bugs to the Gentoo bugzilla in a relatively quick fashion, and there are interested Gentoo users who post proposed fixes.  Once a fix has been provided in Gentoo, it can be pushed upstream by either the author of the fix or the Gentoo maintainer.  This may not be as nice as having it reported directly upstream, but it is more efficient than having Diego try to track down the myriad ways in which upstream providers accept bug reports (e-mail to bugs@, e-mail to some maintainer's personal account, Bugzilla, Mantis, Trac, Google Code, etc.).
Comment 6 Kevin Pyle 2010-09-21 04:14:24 UTC
Created attachment 248244 [details, diff]
Patch to miniupnpd-1.5_pre20091222.ebuild to address numerous issues

This turned out to be more complicated than expected. :)  This ebuild patch fixes the following issues:

- Upstream used uuidgen, but the ebuild did not DEPEND on sys-apps/util-linux to provide uuidgen.
- User CFLAGS were ignored!
- Compilation fails if the kernel was built out-of-tree, since the ebuild inserts a reference to -I${KV_OUT_DIR}/include, but the required headers are in the kernel source tree, not the kernel object tree.  Variable changed to KERNEL_DIR.
- Delete upstream call to genuuid.  The rule did genuuid||uuidgen.  With the dependency on util-linux, we can guarantee uuidgen is available, so do not even try to run genuuid.
- Fix the reported overflows by switching to use sizeof() to compute the available length.  The compiler warned because the wrong magic constant was used, so strncpy was told a larger size than was actually true.
- Missing ||die on the calls to sed.  Calls to sed the Makefile were consolidated and given an ||die.

With regard to the UUID generation, it seems a little questionable to do that in the package installation phase, since then all installations derived from the built package will share a UUID.  This is the same type of problem as affected SSL certificates and led to the use of ssl-cert.eclass.  I do not see any obvious security problems from allowing two miniupnpd instances to share a UUID, but I doubt clients will handle it gracefully.
Comment 7 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2010-09-26 14:07:15 UTC
I have added the patch, and bumped it to 20100921, to hit two birds with one stone.

Please let me know if this fixes the problem.
I cannot get my own machine to produce the fortify sources errors, even with -O2 (newest ~arch gcc and glibc) - so I don't know if they are fixed.

How do I get this enabled? (I cannot seem to find any info on what might be needed that I don't have)
Comment 8 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2011-01-18 21:37:36 UTC
I'm closing this, since nobody is answering, and the patch has been applied. :-)