|
i mean, ultimately the exploit payload was within the lzma test files, and those are ultimately meant to be random junk data anyway even if the m4 macros that were the actual exploit did get caught (and m4 is such an unreadable loving mess that it probably wouldn't have been), i doubt that anyone would have discovered the payload, meaning the exploit vector just has to change. switching to a different build system doesn't really fix anything
|
#
?
Mar 31, 2024 17:57
|
|
|
|
| # ? Jun 3, 2024 22:20 |
|
|
If test files are a convenient way to hide stuff like this, I guess you could try to isolate any test files and exclude them when the actual build is performed or something but maybe that's too complicated and I'm not sure whether it would really work or not
|
|
#
?
Mar 31, 2024 18:00
|
|
|
makefiles and other build scripts are routinely filled with non-human readable machine generated garbage so it's honestly no wonder it was able to slip by, the obfuscated stuff looks like anything else you'd normally see in them
|
|
#
?
Mar 31, 2024 18:03
|
|
|
Beeftweeter posted:i mean, ultimately the exploit payload was within the lzma test files, and those are ultimately meant to be random junk data anyway you'd need to come up with a way for the build system to incorporate test data into the final executable artifacts. it is very difficult to come up with a plausible justification for doing that and it cuts against the grain of how every widely-used build system works. normally you first build the artifacts and then run the test suite against them. a compression algorithm could perhaps introduce a "new and improved" v2 bitstream format that incorporates some opaque tree-structured statistical models (derived from "real-world data", for instance), and it could access them in some complicated way such that the memory safety of those accesses is hard to prove, but at that point you're looking at a very different attack, and none of that changes the fact that openssh doesn't actually do any compression using this library to begin with, it was just the weakest link in /usr/sbin/sshd's ldd output that some nation-state actor could organize a bullying campaign against.
|
|
#
?
Mar 31, 2024 18:07
|
|
|
you could do two builds, one with the regular source distribution, that runs the test suite and fails the build if the test suite fails then for the second build you delete the test suite directory and configure the build to disable the tests, and that's the one that gets uploaded for extra credit check that the first and second build generated the same binary outputs and fail the package build if not this would be pretty easy although unusual with today's linux package building tools although if it becomes a pattern i could see introducing some ergonomics around it via debhelper or whatever would need some way to prevent the first build from tainting the build environment, hmm seems like the primary benefit would be eliminating the test suite as a convenient place to hide things which i guess makes the rest of the commits easier to review
|
|
#
?
Mar 31, 2024 18:08
|
|
|
shackleford posted:you could do two builds, one with the regular source distribution, that runs the test suite and fails the build if the test suite fails Even if you tried to enforce it outside of the actual build scripts by excluding tests based on somehow marking test files, it would probably be possible for someone to just fail to mark some of the test files as part of the tests rather than the builds mystes fucked around with this message at 18:21 on Mar 31, 2024 |
|
#
?
Mar 31, 2024 18:19
|
|
|
If we care about reproducible builds (we do), then tarballs must be constructed from source control in a way that can also be reproduced, if tarballs are used at all. Similarly, anything else in the build that isn't plain text should have some kind of known provenance. Need a text corpus for compression? There are plenty of public domain text files. Other media types have public domain examples you can use. A code repository just sholdn't contain mystery data files. Ultimately, guarding against people abusing the trust of society is extremely hard and putting up more barriers may not even be worth it. You have to trust people or we simply cannot function.
|
|
#
?
Mar 31, 2024 18:23
|
|
|
Sapozhnik posted:you'd need to come up with a way for the build system to incorporate test data into the final executable artifacts. well that's pretty simple: even though it happens to be within m4 macros here, it accomplishes the whole thing using a chain of pretty standard tools (tr, sed, cut, awk, head) that are used for all sorts of crap in build scripts because they're very useful tools so you just need it to be able to execute a chain of commands, which is basically a description of what a build system does
|
|
#
?
Mar 31, 2024 18:25
|
|
|
Antigravitas posted:Similarly, anything else in the build that isn't plain text should have some kind of known provenance. Need a text corpus for compression? There are plenty of public domain text files. Other media types have public domain examples you can use. You could pull in a public example file from the internet but if its some weird binary file how would you know that the file wasn't actually created by the same bad actor? Also if it's a gui application it could have images that you could try to hide stuff in but maybe that would be more obvious? mystes fucked around with this message at 18:30 on Mar 31, 2024 |
|
#
?
Mar 31, 2024 18:27
|
|
|
Antigravitas posted:Similarly, anything else in the build that isn't plain text should have some kind of known provenance. Need a text corpus for compression? There are plenty of public domain text files. Other media types have public domain examples you can use. that's pretty untenable for something like a compression routine. like, even video codecs come with test bitstreams, and if it's some novel format (say, higher resolution or dynamic range than previously possible, so there are no extant examples) then someone wouldn't even know the difference between good code and bad code
|
|
#
?
Mar 31, 2024 18:29
|
|
|
hey speaking of video codecs if you didn't like the chain of dependencies libsystemd pulled in, can i introduce you to literally anything that links against FFmpeg
|
|
#
?
Mar 31, 2024 18:34
|
|
|
shackleford posted:hey speaking of video codecs if you didn't like the chain of dependencies libsystemd pulled in, can i introduce you to literally anything that links against FFmpeg oh i've been thinking about that since the xz exploit was discovered. lol, lmao
|
|
#
?
Mar 31, 2024 18:35
|
|
|
sobs in gstreamer-plugins-bad
|
|
#
?
Mar 31, 2024 18:44
|
|
|
I guess it's good this backdoor wasn't found a month earlier because hopefully there won't be enough time for people to come up with some truly awful april fools jokes based on it
|
|
#
?
Mar 31, 2024 18:49
|
|
|
mystes posted:I guess it's good this backdoor wasn't found a month earlier because hopefully there won't be enough time for people to come up with some truly awful april fools jokes based on it maybe someone could make a poc that uses the backdoor to install a better operating system
|
|
#
?
Mar 31, 2024 21:00
|
|
|
akadajet posted:maybe someone could make a poc that uses the backdoor to install a better operating system liblzma doesn't ship with windows?
|
|
#
?
Mar 31, 2024 21:18
|
|
|
oh no blimp issue posted:liblzma doesn't ship with windows? iirc it uses libarchive, which has an independent implementation
|
|
#
?
Mar 31, 2024 21:21
|
|
|
Beeftweeter posted:i mean, ultimately the exploit payload was within the lzma test files, and those are ultimately meant to be random junk data anyway lzma junk
|
|
#
?
Mar 31, 2024 22:38
|
|
|
shackleford posted:hey speaking of video codecs if you didn't like the chain of dependencies libsystemd pulled in, can i introduce you to literally anything that links against FFmpeg dear maintainers, we believe we have greatly improved the ssh authentication experience by adding support for video banners, and urge you to merge these patches asap
|
|
#
?
Apr 1, 2024 00:12
|
|
|
i think the healthy point to be made there is that there's such a difference between sshd and ffmpeg. notably there is afaik not currently much in a difference in managing the packages and releases, but there probably should be. and i think honestly it is a matter of *less* work, in that openssh and its environment really should change slower than a state where someone can show up and go "i'd like this minor version loaded up plox". i am genuinely kind of excited by the development at this point, because i think it'll lead to pretty healthy developments.
|
|
#
?
Apr 1, 2024 00:16
|
|
|
ffmpeg uses libssh2 i think. or it could be libssh. or i think you can use openssh or libcurl with ssh support tbh there's too many ways of accomplishing the same thing with ffmpeg. if there's more than one library for doing something, it probably supports it, even if it's not really widespread. there's a bunch of janky old poo poo that you can include that hasn't been updated in decades too, like libxvid or libmp3lame (but it's not like they really need updates, so maybe this is good. idk, i have mixed feelings about it) but yeah my typical ffmpeg build has uhh about 40 dependencies i guess. they've been very slowly adding native implementations of some of the older codecs but they're obviously not as polished as something that's had like 20 years of development. it's not ideal, but it's by far the most useful audio/video processing tool out there, so whatchya gonna do
|
|
#
?
Apr 1, 2024 00:28
|
|
|
FFmpeg could dlopen() the external libraries it wants to depend on like SDL, that way at least you aren't exposed to the ELF initialization functions of the closure of all the shared library dependencies, only the ones required for the specific functionality you want to use. i'm sure that idea is anathema to the french anarcho-capitalist collective that governs FFmpeg though a nice example right now is the FFmpeg --enable-pocketsphinx configure flag which enables some kind of speech-to-text plugin. this build flag is currently enabled in debian unstable with --enable-pocketsphinx, libavfilter has a runtime dependency on libsphinxbase libsphinxbase has a runtime dependency on libblas libblas has a runtime dependency on libopenblas the openblas library has an __attribute__((constructor)) function that will run when the library is loaded: https://github.com/OpenMathLib/OpenBLAS/blob/b1e8ba50173423dd1999c7e1bc97c93039efc5e3/driver/others/memory.c#L1507-L1563 which then spins up a thread pool: https://github.com/OpenMathLib/OpenBLAS/blob/b1e8ba50173423dd1999c7e1bc97c93039efc5e3/driver/others/blas_server.c#L648-L718 anyway if you have a program linked against FFmpeg's libavfilter or libavdevice libraries, it'll spin up an openblas thread pool at startup on debian unstable i think it also rummages around in a bunch of random /etc files but i can't remember if that's openblas or something else
|
|
#
?
Apr 1, 2024 00:47
|
|
|
its behavior really depends on what you've configured it with. if you don't use pocketsphinx (and i don't think i ever have), there's no openblas dependency. i'm also not aware of ffmpeg poking around in /etc ever, but again, i've never compiled it with that afaik it's kinda stupid to use some distro package though imo, i never do and always compile my own because of the --enable-version3 and --enable-nonfree config flags lol, a fully-featured ffmpeg is pretty much non-redistributable. its development moves really quickly too, so packages are almost always outdated like, anything even slightly proprietary (think hevc, avc, evc, etc.) will probably require both. you could probably get away with just using av1, opus and ISOBMFF a few years from now but we aint there yet e: that's not to say that rolling your own completely eliminates or even appreciably reduces any potential attack vectors though, of course not. but you do at least get full control over what gets thrown in e2: e.g. this is from 2020 but here's an example of my build config for macos + icc/icpc code:Beeftweeter fucked around with this message at 01:31 on Apr 1, 2024 |
|
#
?
Apr 1, 2024 01:09
|
|
|
BlankSystemDaemon posted:proprietary software vendors don’t have solutions to the issues exposed by this the solution is to have rich states spend the considerable money and manpower resources they have at their disposal paying people to identify the load bearing projects and vet and help maintain them. unfortunately i've been told that government is the problem is not the solution and this kind of thing should be left to the invisible hand, like everything else
|
|
#
?
Apr 1, 2024 02:48
|
|
|
https://twitter.com/FFmpeg/status/1775178805704888726quote:The xz fiasco has shown how a dependence on unpaid volunteers can cause major problems. Trillion dollar corporations expect free and urgent support from volunteers. huh i guess i'm not that surprised but i guess i was kind of expecting the most valuable company in the world, the one that developed V4W, AVI, DirectShow, DirectX, Direct3D, etc. etc. to be able to put on their Principal Software Engineer pants and write some C++ to parse some data out of a file e: lol "Thanks @Elon for the reply,"
|
|
#
?
Apr 3, 2024 21:06
|
|
|
there's licensing issues with open source stuff sometimes, but yeah they probably just don't care enough
|
|
#
?
Apr 4, 2024 02:42
|
|
|
Private Speech posted:there's licensing issues with open source stuff sometimes, but yeah they probably just don't care enough isn't microsoft a part of the MPEG consortium or whatever it's called, the body that causes all of the codec distribution problems?
|
|
#
?
Apr 4, 2024 20:19
|
|
|
Clark Nova posted:isn't microsoft a part of the MPEG consortium or whatever it's called, the body that causes all of the codec distribution problems? probably, but that doesn't mean they're a part of the patent pool, i.e. being a part of the Motion Picture Experts Group (https://www.mpeg.org) does not make you a member of the, uh, VIA LA yep, that VIA (centaur). they bought the whole MPEG-LA: https://www.via-la.com unsurprisingly neither website lists their membership
|
|
#
?
Apr 4, 2024 21:04
|
|
|
broke down and bought a 7900xtx after getting a 4K monitor. it’s nice to be able to put the computer to sleep without everything going haywire on the 3080.
|
|
#
?
Apr 6, 2024 15:57
|
|
|
rusty talking about openblas up there somehow reminded me of gambas, basically visual basic (classic, not .net) for linux and friends anyone played with it? i'd been interested in it since i'd first heard of it, it's been about 25 years since i've developed anything with VB, but it seems kinda neat and (as i would suspect is the case for many of us,) it was the first language i'd learned how to make a gui with idk how it works though, i'd be very surprised if it compiled to some equivalent of p-code e: especially when there's transpilers to c++ like QB64 for loving QBASIC with e.g. opengl extensions and a WYSIWYG pseudo-IDE lol Beeftweeter fucked around with this message at 16:27 on Apr 6, 2024 |
|
#
?
Apr 6, 2024 16:20
|
|
|
Explicit sync
|
|
#
?
Apr 6, 2024 16:57
|
|
|
decided to try out i3 again and its actually pretty cool once you get it all configured i mean i still need to figure out what to put in my config to make f2 and f3 adjust the volume like they did in GNOME (they have little icons for it on the keys themselves and you need to hold fn to use the actual f-key so im guessing its something built into the laptop/specific media keys or something)
|
|
#
?
Apr 6, 2024 17:22
|
|
|
hbag posted:decided to try out i3 again and its actually pretty cool once you get it all configured
|
|
#
?
Apr 6, 2024 17:25
|
|
|
mystes posted:One option is to just run something like xfce4-volumed to handle the media keys. Most of the xfce daemons work pretty well with i3. oh neat ill check that out
|
|
#
?
Apr 6, 2024 17:27
|
|
|
that doesnt seem to be doing it either. do i just have really specific niche media keys or something. what does GNOME use because they worked fine in that
|
|
#
?
Apr 6, 2024 17:44
|
|
|
hbag posted:that doesnt seem to be doing it either. do i just have really specific niche media keys or something. what does GNOME use because they worked fine in that if you want gnome with i3 on top you should check out regolith. that's what I used when I was on popOS for work
|
|
#
?
Apr 6, 2024 17:52
|
|
|
Asleep Style posted:if you want gnome with i3 on top you should check out regolith. that's what I used when I was on popOS for work i want i3 with working media and brightness keys
|
|
#
?
Apr 6, 2024 18:05
|
|
|
use the xev utility to get the names of the keysyms those keys are generating and then bind those keys to some pactl commands to adjust volume
|
|
#
?
Apr 6, 2024 18:14
|
|
|
hbag posted:i want i3 with working media and brightness keys Maybe it's easier just to bind them individually if it seems like it's not working though. I just liked using the xfce volume and power daemons because they worked fine out of the box for me.
|
|
#
?
Apr 6, 2024 18:26
|
|
|
|
| # ? Jun 3, 2024 22:20 |
|
|
shackleford posted:use the xev utility to get the names of the keysyms those keys are generating and then bind those keys to some pactl commands to adjust volume ...well it doesnt seem to give an actual KeyPress and KeyRelease event like all the other keys on the keyboard, instead i get this when i tap f3 (the volume up key): code:
|
|
#
?
Apr 6, 2024 18:27
|
|