| 26 Sep 2024 |
 tgerbet | The exploit does not require user interaction from what I see | 21:06:18 |
 f0x | adding the printer does not, but actually causing RCE does | 21:07:05 |
| f0x | as the filter command in the generated PPD is only executed when actually printing with that printer? | 21:07:42 |
|  p14 joined the room. | 21:07:57 |
| f0x | hmm, although there is a mention that this printer injection path can overwrite existing printers | 21:08:25 |
| f0x | but there doesn't seem to be any evidence of that? | 21:10:25 |
| f0x | might be nice to make the cups-filter binaries that are presented to cups configurable https://github.com/NixOS/nixpkgs/blob/nixos-24.05/nixos/modules/services/printing/cupsd.nix#L39 | 21:25:35 |
| tgerbet | https://github.com/OpenPrinting/cups-browsed/security/advisories/GHSA-rj88-6mr5-rcw8 | 21:34:59 |
| 27 Sep 2024 |
|  夜坂雅 joined the room. | 01:59:55 |
|  l0b0 joined the room. | 02:27:51 |
 hexa | so now that https://github.com/OpenPrinting/cups-filters/security/advisories/GHSA-rq86-c7g6-r2h8 hit | 13:12:37 |
| hexa | what do people think about defaulting to BrowseRemoteProtocols dnssd? | 13:12:48 |
| hexa | also, what is a bit sad is that our configuration is types.lines, and not in any way structured | 13:13:42 |
| tgerbet | We already default to BrowseRemoteProtocols dnssd because we do not use their default configuration file and they default to dnssd if no entry is set for BrowseRemoteProtocols | 13:17:57 |
| hexa | oh, so those defaults are out of sync, that is cute | 13:18:24 |
| tgerbet | Yes, it was part of my surprises last night 😅
That said it would be nice to only open 631/udp in the firewall when needed and not all the time | 13:20:23 |
 Sandro 🐧 | In reply to @hexa:lossy.network
also, what is a bit sad is that our configuration is types.lines, and not in any way structured probably would need to be a custom format because they allow some keywords multiple times and it looks to be order depended 🫠 | 14:47:56 |
| Sandro 🐧 | feels like Apache allow style... | 14:48:11 |
| Sandro 🐧 | * feels like Apache allow style... https://manpages.debian.org/testing/cups-browsed/cups-browsed.conf.5.en.html#:~:text=servers%20are%20accepted.-,BrowseAllow,-All%0A%0A%0A%20%20%20%20%20%20%20%20BrowseAllow%20192.168.7.20 | 14:48:19 |
| Sandro 🐧 | Does upgrading to 2.0 help? | 14:49:28 |
| Sandro 🐧 | * Does upgrading to 2.0.1 help? | 14:49:55 |
| hexa | no | 14:50:38 |
|  @austreelis:the-apothecary.club left the room. | 16:09:07 |
| 28 Sep 2024 |
|  @majiir:matrix.org left the room. | 00:11:31 |
 undltd | How can I verify that a certain port is not "open" on a certain interface / ip on my machine? Like, how can I actually test it without physically going to another machine and nmapping/etc? | 11:14:29 |
| f0x | In reply to @setthemfree:matrix.org
How can I verify that a certain port is not "open" on a certain interface / ip on my machine? Like, how can I actually test it without physically going to another machine and nmapping/etc? with netstat or ss | 11:48:54 |
 aloisw | That doesn't take the firewall into account. | 11:53:24 |
| f0x | In reply to @aloisw:kde.org
That doesn't take the firewall into account. is there anything that does, from the local machine? | 13:36:23 |
 clefru | In reply to @f0x:pixie.town
is there anything that does, from the local machine? Put nmap into a docker container maybe? That should pass the firewall if I recall correctly. | 13:49:08 |
 philipp | I don't think there is a universal answer since firewalls rules are more complex than just "port open or closed". | 15:15:29 |
