Hey,
we have had an off--list discussion with Kai on this (to shorten the
30 mails we exchanged ;-) I am writing this summary). He solved the
issue by --without-bash-malloc which could indicate a bug or lack of
proper support in lib/malloc/malloc.c for his platform. However, we
were unable to get
On 13 Dec 2015 17:24, Chet Ramey wrote:
> On 12/12/15 4:01 PM, Mike Frysinger wrote:
> > Today, if you have a script that lives on a noexec mount point, the
> > kernel will reject attempts to run it directly:
> > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> > $ chmod a+rx /dev/shm/test.
On 13 Dec 2015 12:21, Piotr Grzybowski wrote:
> On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote:
> > On 12 Dec 2015 15:06, Bob Proulx wrote:
> >> It will almost
> >> certainly get in the way of a reasonable use case.
> >
> > can you name a reasonable use case this breaks ?
>
> source /media
On 12 Dec 2015 23:05, Stephane Chazelas wrote:
> 2015-12-12 16:01:26 -0500, Mike Frysinger:
> [...]
> > This is not a perfect solution as it can still be worked around by
> > inlining the code itself:
> > $ bash -c "$(cat /dev/shm/test.sh)"
> > hi
>
> Or
>
> cat /dev/shm/test.sh | bash
right
On 13 Dec 2015 16:50, konsolebox wrote:
> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
> > Today, if you have a script that lives on a noexec mount point, the
> > kernel will reject attempts to run it directly:
> > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> > $ chmod a+rx /d
On 12/12/15 4:01 PM, Mike Frysinger wrote:
> From: Mike Frysinger
>
> Today, if you have a script that lives on a noexec mount point, the
> kernel will reject attempts to run it directly:
> $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> $ chmod a+rx /dev/shm/test.sh
> $ /dev/shm/test.
2015-12-13 12:49:58 -0500, Chet Ramey:
[...]
> I have to tell you, if I wanted to exploit a program written this poorly,
> I wouldn't mess around with SHELLOPTS. I'd go straight to PATH.
[...]
In the (very specific) OP's test case, he had
system("/bin/date"). Since /bin/date doesn't usually execu
Quoting "Chet Ramey" :
On 12/10/15 2:16 PM, up201407...@alunos.dcc.fc.up.pt wrote:
Hello,
This is a suggestion for a bash security hardening patch which prevents
xtrace from being initialized to the SHELLOPTS environment variable when a
new shell starts.
This is far too drastic a solution to
On 12/10/15 2:16 PM, up201407...@alunos.dcc.fc.up.pt wrote:
> Hello,
>
> This is a suggestion for a bash security hardening patch which prevents
> xtrace from being initialized to the SHELLOPTS environment variable when a
> new shell starts.
This is far too drastic a solution to the problem you h
Stepahne,
How do I use it? I am just a starter for linux commands
--
View this message in context:
http://gnu-bash.2382.n7.nabble.com/Ruler-tp16609p16614.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.
2015-12-12 17:53:35 -0500, Mike Frysinger:
[...]
> > It will almost
> > certainly get in the way of a reasonable use case.
>
> can you name a reasonable use case this breaks ?
bash << EOF
some code
EOF
here-documents with many shells (including bash) are implemented
as deleted temporary files (t
2015-12-12 16:01:26 -0500, Mike Frysinger:
[...]
> This is not a perfect solution as it can still be worked around by
> inlining the code itself:
> $ bash -c "$(cat /dev/shm/test.sh)"
> hi
Or
cat /dev/shm/test.sh | bash
I think this kind of hardening is better left to things like
selinux/app
hi,
On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote:
> On 12 Dec 2015 15:06, Bob Proulx wrote:
>> It will almost
>> certainly get in the way of a reasonable use case.
>
> can you name a reasonable use case this breaks ?
source /media/noexecmountpoint/sh/functions.sh;
find_all_files_with_e
On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
> From: Mike Frysinger
>
> Today, if you have a script that lives on a noexec mount point, the
> kernel will reject attempts to run it directly:
> $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> $ chmod a+rx /dev/shm/test.sh
> $ /d
14 matches
Mail list logo
