| Summary: | dev-scheme/bigloo fortify/aborts with gcc-4.5 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | Scheme Project <scheme> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cyprien, hardened |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 296658, 330977 | ||
| Attachments: |
Build log
bigloo-3.3a_p5-gcc45_fortify.patch testcase for x86_64 bigloo-3.3a_p5-gcc45_fortify.patch |
||
|
Description
Diego Elio Pettenò (RETIRED)
2010-05-05 18:04:29 UTC
Created attachment 230517 [details]
Build log
It looks like adding -D_FORTIFY_SOURCE in the CFLAGS make the build successful, even if I don't really grab what does it means... I will attach the patch/new ebuild after having more testing done. Created attachment 244951 [details, diff] bigloo-3.3a_p5-gcc45_fortify.patch Here it is. This patch create a new file in the Bigloo autoconf directory. It needs then to be executable. Here comes a sample ebuild addition: # Fix for bug 318661 epatch "${FILESDIR}/${P}-gcc45_fortify.patch" # as the patch add a new autoconf test, make it executable chmod +x "${S}/autoconf/ccfortify" I'm planning to commit that patch upstream. Dunno when yet. Patch applied upstream for releases >=3.4b. Erm... is bigloo now trying to ignore -D_FORTIFY_SOURCE=2 and thus proceeding with a possibly vulnerable code execution? Really this is _not_ the correct fix, try to debug what is causing __fortify_fail to be called, it's likely an out-of-bound access… maybe hardened team can give us a hand here? (In reply to comment #5) > Erm... is bigloo now trying to ignore -D_FORTIFY_SOURCE=2 and thus proceeding > with a possibly vulnerable code execution? Yes, it lowers the fortify_level to 1 at configure time. > Really this is _not_ the correct fix, try to debug what is causing > __fortify_fail to be called, it's likely an out-of-bound access… maybe > hardened team can give us a hand here? I shortly talked with upstream about that issue, and we didn't give any deep attention to it. There is not a lot of documentation about that feature, apart from the announcement on the gcc list archive (There should be a page somewhere in the Gentoo website about FORTIFY_SOURCE, on either the hardened or QA project' pages, as for -as-needed) As far as I know, FORTIFY_SOURCE=2 is set internally in gentoo's gcc for a while, and the abort only occurs since gcc-4.5. Why? What are the changes on FORTIFY in 4.5.x? My current debug trace show me that the failure comes in Bigloo's (pwd) built-in, which calls getcwd with a freshly allocated string of size 1024, and 1024 for the size. It seems that either the string allocation is wrong, or the call to getcwd is. string_t type is defined in workdir/bigloo/runtime/Include/bigloo.h The C code of (pwd) is in workdir/bigloo/runtime/objs/obj_{s,u}/Llib/os.c BGl_pwdz00zz__osz00 The string allocation is done in workdir/bigloo/runtime/Clib/cstring.c make_string I'm trying to write a small C file reproducing the abort Created attachment 246809 [details]
testcase for x86_64
Test case reproducing the failure, the command-line used to compile:
gcc -O2 -pipe -D_FORTIFY_SOURCE=2 -I/usr/lib/bigloo/3.4b fortify-test.c -L/usr/lib/bigloo/3.4b -L/usr/lib -lbigloo_s-3.4b -lgc -ldl -lm -lgmp -ldl -o fortify-test
It requires a bigloo available, tested it against the last bigloo beta available from the Lisp overlay.
The printf added in my_get_cwd prints "__bos(c_buf)=1", which explains the failure (and actually, a warning is printed at compile-time)
The bigloo string representation seems to be the cause, it use the first char of a string in the string_t structure (char0), instead of the address of this first char (which is obtained from &char0). Is this *that* bad?
Created attachment 247472 [details, diff]
bigloo-3.3a_p5-gcc45_fortify.patch
Backport of upstream changes made in bigloo's trunk
Vulnerable 3.3a version has been removed from the tree, and replaced with 3.4b that already solves this issue. |