On Sat, Apr 13, 2019, 9:43 AM Robert Elz wrote:
> Date:Thu, 11 Apr 2019 19:05:56 -0400
> From:Chet Ramey
> Message-ID: <6973cbca-28bd-5a20-4966-1d8251e95...@case.edu>
>
> | If you want to be sure to shift out all existing parameters, use
> | `shift $#'. If you wa
Date:Thu, 11 Apr 2019 19:05:56 -0400
From:Chet Ramey
Message-ID: <6973cbca-28bd-5a20-4966-1d8251e95...@case.edu>
| If you want to be sure to shift out all existing parameters, use
| `shift $#'. If you want something else, you can add logic to cap the
| argument
On Sat, Apr 13, 2019, 5:56 AM Eli Schwartz wrote:
> But that still isn't a bug in bash. It's more along the lines of a
> social engineering exploit.
>
Kids.
--
konsolebox
>
On 4/12/19 5:56 PM, Vladimir Marek wrote:
> It escapes me how changing your own $PATH makes another user execute
> files in /tmp. And if someone has /tmp in $PATH moreover before anything
> else (or . for that matter) he deserves it. Right?
I assume the idea is to escalate write access to another
It escapes me how changing your own $PATH makes another user execute
files in /tmp. And if someone has /tmp in $PATH moreover before anything
else (or . for that matter) he deserves it. Right?
--
Vlad
> I written an exploit which allow to became root when a normal user use sudo.
> The f
On 4/12/19 5:38 PM, bakzero wrote:
> Hi,
> I written an exploit which allow to became root when a normal user use sudo.
> The following code add to the .bashrc configuration file the /tmp path. Then
> when the user exec sudo he runs the fake one, giving you a root shell. Just
> run it, when the
Hi,
I written an exploit which allow to became root when a normal user use sudo.
The following code add to the .bashrc configuration file the /tmp path. Then
when the user exec sudo he runs the fake one, giving you a root shell. Just run
it, when the normal user will use sudo you will get a root
On Fri 2019-04-12 12:05:24 -0400, Chet Ramey wrote:
> But the execs mean that the shell that is eventually invoked to run the
> `wait' is the parent of the process substitution. So the subshell has
> children, whether or not it has run the process substitution itself.
Yes, agreed. This is the sit
On 4/11/19 6:00 PM, Дилян Палаузов wrote:
> Hello,
>
> as alioth.debian.or is down, replace at
> https://www.gnu.org/software/bash/manual/html_node/A-Programmable-Completion-Example.html
> the reference from http://bash-completion.alioth.debian.org/ to
> https://salsa.debian.org/debian/bash-com
On 4/12/19 12:12 PM, Andrew Church wrote:
>> This recursive function causes bash to segfault:
>>
>> $ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
>> fi; re; }; re
>> Segmentation fault (core dumped)
>>
>> Ideally Bash ought to run out of memory before this fails. But an
>> ac
>This recursive function causes bash to segfault:
>
>$ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
>fi; re; }; re
>Segmentation fault (core dumped)
>
>Ideally Bash ought to run out of memory before this fails. But an
>acceptable solution could also be to say 'stack overflow'.
This recursive function causes bash to segfault:
$ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
fi; re; }; re
Segmentation fault (core dumped)
Ideally Bash ought to run out of memory before this fails. But an
acceptable solution could also be to say 'stack overflow'.
$ bash
On Fri, Apr 12, 2019 at 10:32 PM Chet Ramey wrote:
>
> On 4/11/19 3:08 PM, konsolebox wrote:
>
> >>> It has slightly inconvenient semantics, in that you can't open it more
> >>> than once, and if you can't do that, you can't convert it from read-write
> >>> to readonly.
> >>
> >>
> >> Perhaps it c
On 4/11/19 6:03 PM, Daniel Kahn Gillmor wrote:
> https://bugs.debian.org/920455
It wouldn't really affect that. The reason `wait' waits for process
substitution processes is that they set $!, making them "known to the
shell" and subject to wait without arguments.
On 4/11/19 3:08 PM, konsolebox wrote:
>>> It has slightly inconvenient semantics, in that you can't open it more
>>> than once, and if you can't do that, you can't convert it from read-write
>>> to readonly.
>>
>>
>> Perhaps it can be reopened via /dev/fd.
>
> Also file sealing maybe. The way it
15 matches
Mail list logo
