| 31 Oct 2024 |
 K900 | That's not dependency resolution | 16:01:35 |
 puck | In reply to @emilazy:matrix.org
I believe the CVSS in https://github.com/NixOS/nix/security/advisories/GHSA-wf4c-57rh-9pjg is inaccurate. "Attack Complexity: High" seems inaccurate as it's trivial to reproduce and can be easily deployed from a random flake. "Confidentiality: Low" also seems untrue since it's precisely about builds being able to read things they shouldn't be able to. it might not be a very impactful vulnerability, but there's no way it's a CVSS 1.0. note that CVSS quantifies impact of the vulnerability if you run into it, not how likely you are to run into it. i ..think it should probably be UI:N, and AC:L? i also don't think the bug itself would be AT:P | 16:01:46 |
| K900 | That's just computing dependencies between packages | 16:01:50 |
| K900 | Which is not the slow part | 16:01:55 |
| K900 | And never was | 16:01:57 |
| K900 | And is in fact very fast | 16:02:01 |
| K900 | Specifically because it does not involve "resolution" | 16:02:09 |
 emily | I think AT:P implies that the actual attacker has to be present at the machine, so I agree that that part is inaccurate too. | 16:02:21 |
| puck | In reply to @emilazy:matrix.org
I think AT:P implies that the actual attacker has to be present at the machine, so I agree that that part is inaccurate too. that'd be AV:P i think | 16:02:41 |
| puck | AT:P just means the system has to be misconfigured | 16:02:49 |
| emily | sigh why do tehy have to use inscrutable acronyms | 16:03:05 |
| emily | * sigh why do they have to use inscrutable acronyms | 16:03:12 |
 .. | are there areas where they need mathematical optimization? | 16:03:26 |
| emily | in any case it's definitely not 1.0 and I hope the CVSS score wasn't just massaged to make it so… | 16:03:29 |
| emily | In reply to @khaleghi:matrix.org
are there areas where they need mathematical optimization? we explicitly don't do any kind of SAT or anything | 16:03:59 |
| emily | unlike almost every other package manager :) | 16:04:05 |
| K900 | In reply to@khaleghi:matrix.org
are there areas where they need mathematical optimization? Not really, no | 16:04:19 |
| K900 | At this point the slowest part of Nix is, by a long shot, the interpreter itself | 16:04:32 |
| K900 | And that needs less fancy maths and more rolling up sleeves and profiling for a week | 16:04:50 |
| puck | In reply to @emilazy:matrix.org
in any case it's definitely not 1.0 and I hope the CVSS score wasn't just massaged to make it so… if i change it to CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N it ends up a 2.4 | 16:04:58 |
| puck | the big issue is this vuln kinda depends on other vulns, and the sandbox isn't really default | 16:06:23 |
| emily | VC:L seems wrong, since the impact is itself to confidentiality (if you, say, rely on the Nix sandbox on a host that has sensitive information but then deploy binaries to separate hosts without that information that nonetheless now have access to data they shouldn't?) | 16:06:35 |
| puck | * the big issue is this vuln kinda depends on other vulns to be properly exploitable, and the sandbox isn't really default | 16:06:41 |
| puck | In reply to @emilazy:matrix.org
VC:L seems wrong, since the impact is itself to confidentiality (if you, say, rely on the Nix sandbox on a host that has sensitive information but then deploy binaries to separate hosts without that information that nonetheless now have access to data they shouldn't?) you can't overwrite existing store paths, only create new ones (that Nix won't fully consider valid) | 16:07:03 |
| emily | I guess AT:P is actually accurate to capture that you have to have enabled the sandbox to be vulnerable to it (otherwise you're… unconditionally vulnerable?) | 16:07:14 |
| emily | I was thinking more the read end of things. | 16:07:26 |
| puck | In reply to @emilazy:matrix.org
I was thinking more the read end of things. oh yeah, that's a bigger issue, but also it'd have to be world readable. | 16:07:59 |
| puck | In reply to @emilazy:matrix.org
I guess AT:P is actually accurate to capture that you have to have enabled the sandbox to be vulnerable to it (otherwise you're… unconditionally vulnerable?) yeah, so i think AT:N might be reasonable here | 16:08:30 |
| emily | world readable like a secret in /nix/store that's totally fine because all local users are trusted and we have the sandbox enabled? :) | 16:08:30 |
 connor (burnt/out) (UTC-8) | In reply to @joerg:thalheim.io
connor (he/him) (UTC-7): ok. I could imagine that it takes more cpu time to lookup those nested datastructure (i.e. pointer chasing). I suppose you didn't look at memory usage in comparison? I did; it allocates more memory from what I remember. I’ll try to update the numbers section with the output. | 16:08:45 |
