4 ms·

https://www.openwall.com/lists/oss-security/2023/10/03/2 https://www.openwall.com/lists/oss-security/2023/10/03/2 is probably a better link (without ads and unn

by lfittl 3y ago

https://www.openwall.com/lists/oss-security/2023/10/03/2 https://www.openwall.com/lists/oss-security/2023/10/03/2 is probably a better link (without ads and unnecessary images), which is essentially what the article is citing 1:1.

1vuio0pswjnm7 3y ago
Looney Tunables: Local Privilege Escalation in the glibc's ld.so (CVE-2023-4911)
- TacticalCoder 3y ago
  Are you sure it's the correct CVE? That one is fixed in Debian stable (and probably others): https://security-tracker.debian.org/tracker/CVE-2023-4911 https://security-tracker.debian.org/tracker/CVE-2023-4911
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
  - justinludwig 3y ago
    Yes, that's the CVE referenced by the Phoronix article and the oss-security post. The researchers coordinated their disclosure with the security teams from the major Linux distros, so packages with the fix should be available for most of them today.
userbinator 3y ago
Reading these parts of the analysis... for each GLIBC_TUNABLES that it finds, it makes a copy of this variable (at line 284), calls parse_tunables() to process and sanitize this copy (at line 286), and finally replaces the original GLIBC_TUNABLES with this sanitized copy (at line 288) To sanitize the copy of GLIBC_TUNABLES (which should be of the form "tunable1=aaa:tunable2=bbb"), parse_tunables() removes all dangerous tunables (the SXID_ERASE tunables) from tunestr, but keeps SXID_IGNORE and NONE tunables ...already made me expect what I'd see, and indeed the code there is quite unnecessarily complex. The first simplification I'd do is not make a copy of the variable's value, and the second one is to use the standard C string functions extensively; it's notable that there's no occurrence of strchr() anywhere in that function, despite it being a very useful function for parsing key-value pairs.
- pantalaimon 3y ago
  strtok would be the function to use, it’s silly to open-code it like that
stevekemp 3y ago
Yeah I linked to that same writeup in this earlier piece: https://news.ycombinator.com/item?id=37754973 https://news.ycombinator.com/item?id=37754973 I guess this isn't entirely a duplicate thread though.
eviks 3y ago
But then this link is unreadable on a phone since the text doesn't reflow

by lfittl 3y ago

1vuio0pswjnm7 3y ago

Looney Tunables: Local Privilege Escalation in the glibc's ld.so (CVE-2023-4911)

TacticalCoder 3y ago
Are you sure it's the correct CVE? That one is fixed in Debian stable (and probably others): https://security-tracker.debian.org/tracker/CVE-2023-4911 https://security-tracker.debian.org/tracker/CVE-2023-4911
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- justinludwig 3y ago
  Yes, that's the CVE referenced by the Phoronix article and the oss-security post. The researchers coordinated their disclosure with the security teams from the major Linux distros, so packages with the fix should be available for most of them today.

userbinator 3y ago

Reading these parts of the analysis... for each GLIBC_TUNABLES that it finds, it makes a copy of this variable (at line 284), calls parse_tunables() to process and sanitize this copy (at line 286), and finally replaces the original GLIBC_TUNABLES with this sanitized copy (at line 288) To sanitize the copy of GLIBC_TUNABLES (which should be of the form "tunable1=aaa:tunable2=bbb"), parse_tunables() removes all dangerous tunables (the SXID_ERASE tunables) from tunestr, but keeps SXID_IGNORE and NONE tunables ...already made me expect what I'd see, and indeed the code there is quite unnecessarily complex. The first simplification I'd do is not make a copy of the variable's value, and the second one is to use the standard C string functions extensively; it's notable that there's no occurrence of strchr() anywhere in that function, despite it being a very useful function for parsing key-value pairs.

pantalaimon 3y ago
strtok would be the function to use, it’s silly to open-code it like that

stevekemp 3y ago

Yeah I linked to that same writeup in this earlier piece: https://news.ycombinator.com/item?id=37754973 https://news.ycombinator.com/item?id=37754973 I guess this isn't entirely a duplicate thread though.

eviks 3y ago

But then this link is unreadable on a phone since the text doesn't reflow