Re: Security Vulnerability Reporting

2016-02-26 Thread Chet Ramey 
On 2/26/16 11:13 AM, Dan Douglas wrote:
> On Fri, Feb 26, 2016 at 10:02 AM, Eric Blake  wrote:
>> Very few bugs in bash are security vulnerabilities (shellshock being the
>> obvious exception).  Yes, bash has bugs, but in most cases, what people
>> think are security bugs in bash are actually poorly-written shell
>> functions that crash for the user, but which can't exploit bash to
>> escalate the user's privileges.
> 
> All true. To be a genuine issue it usually has to be something that
> causes a security problem in programs that utilize bash independent of
> the script being run, or which exploits some common aspect of any script
> that couldn't have been foreseen. The script is usually to blame.

The only real security vulnerability was the original exported-functions
shellshock bug.  The rest of the bugs that were subsequently discovered
were not vulnerabilities per se: you could crash the shell but not obtain
elevated privileges.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Security Vulnerability Reporting

2016-02-26 Thread Dan Douglas 
On Fri, Feb 26, 2016 at 10:02 AM, Eric Blake  wrote:
> Very few bugs in bash are security vulnerabilities (shellshock being the
> obvious exception).  Yes, bash has bugs, but in most cases, what people
> think are security bugs in bash are actually poorly-written shell
> functions that crash for the user, but which can't exploit bash to
> escalate the user's privileges.

All true. To be a genuine issue it usually has to be something that
causes a security problem in programs that utilize bash independent of
the script being run, or which exploits some common aspect of any script
that couldn't have been foreseen. The script is usually to blame.

-- 
Dan Douglas

Re: Security Vulnerability Reporting

2016-02-26 Thread Dan Douglas 
On Fri, Feb 26, 2016 at 8:54 AM, Travis Garrell
 wrote:
> Is there a set process in place for reporting security vulnerabilities
> against bash? If so, what might that process be?

Mail the maintainer. See:
https://tiswww.case.edu/php/chet/bash/bashtop.html#Bugs
Encrypt with: https://tiswww.case.edu/php/chet/gpgkey.asc

-- 
Dan Douglas

Re: Security Vulnerability Reporting

2016-02-26 Thread Eric Blake 
On 02/26/2016 07:54 AM, Travis Garrell wrote:
> Good Morning/Afternoon/Evening,
> 
> Is there a set process in place for reporting security vulnerabilities
> against bash? If so, what might that process be?

Very few bugs in bash are security vulnerabilities (shellshock being the
obvious exception).  Yes, bash has bugs, but in most cases, what people
think are security bugs in bash are actually poorly-written shell
functions that crash for the user, but which can't exploit bash to
escalate the user's privileges.

So unless you are dead certain you have another shellshock equivalent on
your hands (where bash could be coerced into running arbitrary code that
was NOT part of the shell script, in such a way that anyone using bash
as /bin/sh via system() calls made those programs become an escalation
point), then posting your example to this list is probably okay, at
which point we can confirm that it is not a security bug.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Security Vulnerability Reporting

2016-02-26 Thread Travis Garrell 

Good Morning/Afternoon/Evening,

Is there a set process in place for reporting security vulnerabilities 
against bash? If so, what might that process be?


Thank you much!

Regards,
Travis Garrell

Re: [minor] "precision" of $SECONDS

2016-02-26 Thread Chet Ramey 
On 2/25/16 12:20 PM, Stephane Chazelas wrote:
> 2016-02-25 10:48:51 -0500, Chet Ramey:
> [...]
>> Because bash doesn't have floating point arithmetic.
> 
> Yes, makes sense. mksh having $EPOCHREALTIME floating point even
> though it doesn't have floating point arithmetic does sound
> weird.
> 
> Any plan of adding floating point arithmetic support to bash by
> the way?

It's not on the short-term feature list.


>> Bash's %T implementation doesn't have %N because it uses the libc
>> strftime(3), and as far as I know, no strftime provides it.  I assume
>> that ksh93 implements it internally as part of libast.
> [...]
> 
> Probably. Note that GNU date also has a %N and doesn't use
> strftime either. strftime taking a struct tm can't have
> subseconds anyway.

GNU date uses its own time-string-formatting function, derived from
strftime and extended to include things like %N.

Bash includes Aharon Robbins's open-source strftime for those systems
that don't have it; I suppose I could extend that and use it
unconditionally.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/