Open Source Security Mailing List

Discussion of security flaws, concepts, and practices in the Open Source community

List Archives

Latest Posts

Re: shell wildcard expansion (un)safety Fay Stegerman (Nov 10)
* Eli Schwartz <eschwartz () gentoo org> [2024-11-10 00:59]:
[...]

[...]

Obviously, shell scripts and wildcards are one of the easiest ways to trip up
here. But the underlying issue is that CLI interfaces mix options and
arguments: the lack of a clean separation between data and code/commands
(another example is e.g. printing unescaped control characters to stdout,
something discussed on this list before, and far too common IME, as I...

Re: shell wildcard expansion (un)safety Jeroen Roovers (Nov 10)
Also available on that very site:

https://mywiki.wooledge.org/BashPitfalls?action=recall&rev=329#Filenames_with_leading_dashes

and specifically as those changes you mentioned, on that site:

https://mywiki.wooledge.org/BashPitfalls?action=diff&rev1=326&rev2=327

Kind regards,
jer

Re: shell wildcard expansion (un)safety lists (Nov 10)
That says nothing about the amusing character # either at the
start of a name or after whitespace.

Re: shell wildcard expansion (un)safety Eli Schwartz (Nov 10)
The earliest version of the Bash Pitfalls guide that includes a warning
about the topic, per the Wayback Machine:

https://web.archive.org/web/20090426020027/https://mywiki.wooledge.org/BashPitfalls#Filenames_with_leading_dashes

Overall, wildcards are just a classic "here is a programming language
footgun, we cannot fix it because the language is backwards compatible
to the 90s and earlier" which amounts to:

people love bash because...

4 recent security bugs in GNOME's libsoup Alan Coopersmith (Nov 09)
https://gitlab.gnome.org/Teams/Releng/security/-/wikis/home lists four security
vulnerabilities reported against libsoup since June 2024, none of which have
CVE id's listed as being assigned. (For those not familiar with it, libsoup is
an HTTP client/server library for the GNOME desktop.)

1) Request smuggling via stripping of null bytes from the ends of header names
https://gitlab.gnome.org/GNOME/libsoup/-/issues/377

"When...

Re: shell wildcard expansion (un)safety Dominik Czarnota (Nov 08)
This is known since even earlier by the article/disclosure „unix wildcards
gone wild”:
https://seclists.org/fulldisclosure/2014/Jun/136

The original article link seems to not work but it can be seen e.g. here:
https://github.com/Gandosha/gandosha.github.io/blob/master/DefenseCode_Unix_WildCards_Gone_Wild.txt

It shows that in some cases this can lead to code execution, e.g. with „tar
*”

CVE-2024-50378: Apache Airflow: Secrets not masked in UI when sensitive variables are set via Airflow cli Ephraim Anierobi (Nov 08)
Severity: low

Affected versions:

- Apache Airflow before 2.10.3

Description:

Airflow versions before 2.10.3 have a vulnerability that allows authenticated users with audit log access to see
sensitive values in audit logs which they should not see. When sensitive variables were set via airflow CLI, values of
those variables appeared in the audit log and were stored unencrypted in the Airflow database. While this risk is
limited to users...

Re: shell wildcard expansion (un)safety Georgi Guninski (Nov 08)
This is known since at least 2019, but the distro list can't tell
vulnerability from a rant [1] [2]

`grep text -- *` is not portable solution, since not all warez recognize --.

e.g.:

$find . --
find: unknown predicate `--'

[1] Shell wildcards considered dangerous?
https://seclists.org/oss-sec/2019/q4/133

[2] https://www.linkedin.com/pulse/careful-wildcards-linux-rm-georgi-guninski-ieaif

Re: CVE-2024-35235 cups: Cupsd Listen arbitrary chmod 0140777 Solar Designer (Nov 07)
Yes, here's a blog post on the Ubuntu exploit chain:

Abusing Ubuntu 24.04 features for root privilege escalation
Written by: Rory McNamara
September 9, 2024
40 mins read

https://snyk.io/blog/abusing-ubuntu-root-privilege-escalation/

This is a lot. I only skimmed. wpa_supplicant and CUPS got CVEs, but
really it's not so obvious what component(s) to blame/fix.

I've attached my plain text export of the blog post to this message....

Re: shell wildcard expansion (un)safety Steffen Nurpmeso (Nov 07)
Mats Wichmann wrote in
<a0a83f75-de97-4cb1-9e8e-0cad322fd31f () wichmann us>:
|On 11/7/24 14:41, Steffen Nurpmeso wrote:
|> So it standardizes behaviour as it exists in real life
|> applications.
|> (This is pretty unfortunate.)

|As I'm sure you know, standards workgroups tend to operate in accordance
|with a charter that bounds their work. These vary widely depending on
|circumstances and the chartering...

Re: shell wildcard expansion (un)safety Solar Designer (Nov 07)
Actually, to me the above reads like it merely allows the current
behavior ("may"), but encourages change ("should"). That's good.

My only complaint is that "ignore" doesn't suggest this resulting in a
non-zero exit status from xargs. POSIX allows exit status in the range
of 1 to 125 if, among other possibilities, "some other error occurred".
So I think a non-zero exit status in that range on...

Re: shell wildcard expansion (un)safety Mats Wichmann (Nov 07)
As I'm sure you know, standards workgroups tend to operate in accordance
with a charter that bounds their work. These vary widely depending on
circumstances and the chartering organization(s), but it's not uncommon
for projects - POSIX being one of those -to be set up to standardize
existing practice to provide incentive for various implementations not
to end up diverging from such practice without good reason. It's a
little...

Re: shell wildcard expansion (un)safety Steffen Nurpmeso (Nov 07)
Steffen Nurpmeso wrote in
<20241107210420.v7ZcHYHZ@steffen%sdaoden.eu>:
|Solar Designer wrote in
| <20241107041658.GA10363 () openwall com>:
||On Thu, Nov 07, 2024 at 01:08:19AM +0100, Steffen Nurpmeso wrote:
||> David A. Wheeler wrote in
||> <F60236E0-F65A-4441-9E62-64EE55016B2C () dwheeler com>:
||>|> On Nov 5, 2024, at 11:12 PM, Solar Designer <solar () openwall com> \
||>|> wrote:
||>|...

Re: shell wildcard expansion (un)safety Steffen Nurpmeso (Nov 07)
Solar Designer wrote in
<20241107041658.GA10363 () openwall com>:
|On Thu, Nov 07, 2024 at 01:08:19AM +0100, Steffen Nurpmeso wrote:
|> David A. Wheeler wrote in
|> <F60236E0-F65A-4441-9E62-64EE55016B2C () dwheeler com>:
|>|> On Nov 5, 2024, at 11:12 PM, Solar Designer <solar () openwall com> wrote:
|>|
|>|> ... over the years we gained things like ...
|>|>
|>|> find . -mindepth 1...

Re: shell wildcard expansion (un)safety Max Nikulin (Nov 07)
Even this technique might have consequences unexpected by script
authors, see

<https://mywiki.wooledge.org/BashPitfalls#pf42>:

The original issue is #3 in this list:
<https://mywiki.wooledge.org/BashPitfalls#pf3>
"Filenames with leading dashes"
It is discussed in the pitfall #2 and some
<https://mywiki.wooledge.org/BashFAQ>
entries.

I am not trying to dispute that expanding leading dash to "./-" by...

More Lists

Dozens of other network security lists are archived at SecLists.Org.