On Thu, Sep 25, 2014 at 5:09 PM, Rick Miller <vmil...@hostileadmin.com> wrote:
> > > On Thu, Sep 25, 2014 at 4:51 PM, Rick Miller <vmil...@hostileadmin.com> > wrote: > >> >> >> On Thu, Sep 25, 2014 at 3:05 PM, Guido Falsi <m...@madpilot.net> wrote: >> >>> On 09/25/14 20:57, Rick Miller wrote: >>> > On Thu, Sep 25, 2014 at 10:43 AM, Guido Falsi <m...@madpilot.net> >>> wrote: >>> > [snip] >>> >> > >>> > =======================<phase: patch >>> >============================ >>> > ===> Patching for bash-4.3.24 >>> > ===> Applying distribution patches for bash-4.3.24 >>> > ===> Applying extra patch >>> /distfiles/local-patches/8_4-amd64/bash.patch >>> > ===> Applying extra patch >>> > /usr/ports/shells/bash/files/extrapatch-colonbreakswords >>> > ===> Applying extra patch >>> > /usr/ports/shells/bash/files/extrapatch-implicitcd >>> > ===> Applying FreeBSD patches for bash-4.3.24 >>> > >>> =========================================================================== >>> > >>> > The first sign that something didn't appear to have gone as expected >>> was >>> > that the package was built as bash-4.3.24.tbz as opposed to >>> > bash-4.3.25.tbz. The above test was executed observing the behavior >>> of a >>> > still vulnerable binary. >>> >>> The way you are applying the patch simply modifies the code being >>> compiled by the port, you're not patching the port itself, so the port >>> maintains the same version number. >>> >> >> Makes sense >> >> >> >>> > The test was performed on an 8.4 host with a [unpatched] bash-4.3.24 >>> after >>> > forcefully removing the package and adding the new, patched package. >>> It >>> > complained of dependencies on packages that were already installed, >>> but not >>> > up to the version of the dependency. After manually fixing these >>> > dependencies (forcefully deleting the existing dependencies and >>> installing >>> > the new ones), the test was executed once again to the same results. >>> > >>> > Could this be an issue of the order the patches were applied in or ?? >>> >>> You should check the build log and see if in the patching phase there >>> was any error. >>> >> >> The above log snippet is from the patch phase of the build indicating >> success (well, at least no error). A build with the wrong patch was >> attempted that did indicate errors, as expected. >> >> The full log can be viewed at http://pastebin.com/hwHwJAKK >> >> Is there some way in the log to identify if the source was patched and >> built correctly? Does Poudriere [ I say Poudriere realizing that it likely >> does not, but perhaps the system does? ] provide the ability to review the >> source code after patching to actually verify the patch was applied? A >> cursory search of the filesystem where Poudriere stores the jail turned up >> no leads. >> > > The patch does apply to evalstring.c which shows the following warnings in > the build log though I am unfamiliar enough to know whether or not this > would apply to this particular scenario. > > cc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include -I../lib -I. > -I/usr/local/include -O2 -pipe -fno-strict-aliasing evalstring.c > evalstring.c: In function 'parse_and_execute': > evalstring.c:208: warning: passing argument 1 of 'sigemptyset' discards > qualifiers from pointer target type > evalstring.c:209: warning: passing argument 3 of 'sigprocmask' discards > qualifiers from pointer target type > evalstring.c:288: warning: passing argument 2 of 'sigprocmask' discards > qualifiers from pointer target type > evalstring.c: In function 'parse_string': > evalstring.c:444: warning: passing argument 1 of 'sigemptyset' discards > qualifiers from pointer target type > evalstring.c:445: warning: passing argument 3 of 'sigprocmask' discards > qualifiers from pointer target type > evalstring.c:497: warning: passing argument 2 of 'sigprocmask' discards > qualifiers from pointer target type > After reading an extensive thread about this, I was able to "reliably" test the immediate threat which does mitigate the initial risk. Having said that, there is ongoing discussion about a more long term solution. -- Take care Rick Miller _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
