These aren't new aspects of the bug. The fact is that default operation of systems using bash as the shell for interpolation with system or for scripts interpreted by bash allows remote code execution by taking strings from untrusted sources (e.g. USER_AGENT in web servers) and passing them through the environment, which allows remote code execution. What you're reporting here is instances of the resulting problem in products matching this description, not fundamental changes to the understanding of the bug.
What's been difficult is that Red Hat's security response team and bash upstream initially differed on the scope of the issue and thus patching, as Red Hat believed there were broader problems and that upstream patches were therefore too limited in scope. Red Hat was subsequently shown to be correct. The confusion is that there are a number of CVEs out there, and the patches went out in batches. There are quite a variety of tests proposed for the fully documented CVEs, and some of the CVEs remain embargoed, with Red Hat simply advising that people take patches which bash upstream subsequently accepted. On 6 October 2014 18:58, The Outsider <openindi...@out-side.nl> wrote: > Search q-nap & shellshock and you see how deep this goes... > > > On 6 oktober 2014 19:28:00 David Brodbeck <bro...@uw.edu> wrote: > > On Thu, Oct 2, 2014 at 8:12 AM, Alan Coopersmith < >> alan.coopersm...@oracle.com> wrote: >> >> > On 10/ 2/14 07:00 AM, Brandon Hume wrote: >> > >> >> On many (most? all?) Linuxes, /bin/sh *is* /bin/bash. >> >> >> > >> > Many, but not all - the Debian family and some others use a lighter >> weight, >> > POSIX compatible shell instead, dash, the Debian Almquist Shell; and >> many >> > embedded distros use BusyBox instead. >> > >> > https://en.wikipedia.org/wiki/Almquist_shell >> > http://lwn.net/Articles/343924/ >> >> >> >> A big driver of this was faster boot, since boot scripts run on /bin/sh. >> On some systems the startup time for all those bash processes was a >> considerable portion of the total boot time. >> >> Note: It's not enough to make sure no CGI scripts are being run with >> /bin/bash. You also need to make sure no bash processes are being >> launched >> by other scripts, since many scripting languages launch a shell to run >> external commands. Unless the environment is explicitly cleared these are >> likely to inherit the environment of the calling process, with all the >> nasties in it. >> >> -- >> D. Brodbeck >> System Administrator, Linguistics >> University of Washington >> GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875 >> _______________________________________________ >> openindiana-discuss mailing list >> openindiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss >> > > > > _______________________________________________ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
