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 poorl
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 th
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.ed
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)
* expands to all the files in the current working directory, as can be
seen with:
echo *
if you just run:
*
then you will be running the first file of them.
*But* if you have a program that allows to provide an arbitrary "*" as
the first command parameter, it would allow inserting the name of
Rakesh Mane writes:
> In real life, if an attacker founds a command injection vulnerability in
> some system then he can use this flaw to bypass filters or waf's by simply
> uploading a file having a command as filename (example: reboot) and then by
> sending "*" as command.
Sending arbitrary co
