@whitequark @thephd My understanding is the target command is executed as the lp user after dropping privileges. It's not some deep CUPS vuln causing an unexpected RCE, it's largely functionality that is Working Insecurely As Intended and a couple stupid logic bugs that fail to stop it from actually being exploitable.
Posts
-
It's very cute how everyone's like "THIS DOESN'T AFFECT LINUX SERVERS, WHAT A NOTHING BURGER" -
It's very cute how everyone's like "THIS DOESN'T AFFECT LINUX SERVERS, WHAT A NOTHING BURGER"@thephd To be fair as far as I can tell Fedora doesn't even ship with cups-browsed enabled by default, nor the firewall hole to allow it inbound UDP.
And then the whole thing is remote code execution... as the lp user. Which on any reasonably configured system shouldn't be able to do things like read your home directory.
And you need to actually print to the printer to trigger it.
If it doesn't affect servers, and it only affects some desktop distros, and it needs user action (and a user action that isn't that common these days), and it's highly unlikely to be triggerable remotely for most desktop systems (firewalled or NATed) so you need LAN access, and at the end of the day it's only code execution as a limited privileges system user... then yeah, it pretty much qualifies as a nothingburger.
Distros will patch this, desktop users will update their system (happens a lot more consistently than servers), and life will move on with most likely zero exploited users.
-
Facts about hardware are not copyrightable.Facts about hardware are not copyrightable.
People tend to ascribe magical properties to copyright, as if any kind of information whatsoever is copyrightable. That's not how it works.
Copyright is intended to protect creative works. Hardware devices are not considered creative devices, they are functional. They are protected by patent rights, not copyright – and patent rights only protect the ability to reproduce the device, not describe it.
This means that PCB layouts are not copyrightable. By extension, nor are circuit netlists (i.e. the "information" within a circuit schematic). (Yes, this has interesting implications for open source hardware! You can attach licenses all you want to OSHW, but they only protect the actual source design files - anyone can just copy the functional design manually and manufacture copies and ignore the license, as long as they change the name to not run into trademark issues/etc., any firmware notwithstanding)
IC masks are protected under a very explicit law in the US. They weren't before that. By extension, nothing else about the chip design other than possibly firmware is copyrightable.
If you go and make an x86 clone or an unlicensed ARM core, Intel and ARM won't go after you for copyright violation. They will go after you for patent infringement, because the ISAs are patented. Talking about the architectures and writing code for them and any other research is perfectly fine. The only thing you can't do is reimplement them.
This is why projects like Asahi Linux can exist. If somehow just knowing how hardware works were a potential copyright violation, none of this would be possible.
What this means is: it is entirely legitimate to inspect things like vendor tools and software to learn things about the hardware, and then transfer that knowledge over to FOSS. You may run into license/EULA issues depending on what you do with the source data specifically (think: "no reverse engineering" type provisions), but as far as the knowledge contained within is concerned, that is not copyrightable, and the manufacturer has no copyright claim over the resulting FOSS.
This includes copying register names. I have an actual lawyer's opinion on that (via @bunnie). I tend to rewrite vendor register names more often than not anyway because often they are terrible, but I'm not legally required to.
The reason why we don't just go and throw vendor drivers into Ghidra and decompile all day, besides the EULA implications for the person doing it, is that the code is copyrightable and it can become a legal liability if you end up writing code that drives the hardware the same way, including in aspects that are deemed creative and copyrightable. This is why we have things like the clean-room approach and why we prefer things like hardware access tracing over decompilation.
But stuff like register names and pure facts about the hardware like that? Totally fair game.
Fun fact: Vendor documentation, like the ARM Architecture Reference Manual, has no copyright release for this stuff in the license. If register names were copyrightable, then anyone who has ever read ARM docs and copied and pasted a reg name into their code would be infringing copyright. They aren't, because this stuff isn't copyrightable.