[10:24] Hi - I was suggested to try here from #ubuntu-bugs - I need to file a bug report with usg, but it can't seem to be done through conventional (apport/launchpad) means. Does anyone know how I might be able to do it? [10:27] sarnold: ^ [10:37] sbdj, https://github.com/canonical/ubuntu-security-guide [10:53] Thanks. It seems the bug is actually in the benchmark itself, which is built by Ubuntu Security Guide, so hopefully they can help - although I note the actual benchmarks aren't part of the repo so maybe not... [11:02] sbdj, no problem, that's still the place to report bugs in usg or the benchmarks [11:04] Thanks :) [11:05] sbdj, could include which benchmark you are using and the lp bug you mentioned [11:14] Done :) [11:14] sbdj, have you set the variable var_sshd_allow_groups_valid to aad_admins? [11:18] Well that makes me an idiot then :D [11:18] If I've missed that, then there's a good chance I've missed other stuff too - have I overlooked some documentation on how to set this up? [11:19] sbdj, I actually didn't work on CIS specifically, but I think that rule needs some manual steps. I will need to check the documentation and so on and will let you know in the ticket :) [11:20] Thanks, appreciated. There doesn't actually seem to be much documentation at all that I can find. [11:23] if you need to update any tests etc, the OpenScap repo is at https://github.com/ComplianceAsCode/content [11:25] and that isn’t really a smooth experience to be honest [11:25] The benchmarks in that repo are actually slightly different from the USG ones [11:28] sbdj, thanks for reporting it [11:29] No problem, always happy to help out [11:29] Hopefully it's user error [11:30] "No SCAP content is provided in this repository, but scripts are available in the tools/ directory that assists with copying the SCAP content into place." [11:30] Oh, are there (internal) USG repos? [11:31] I would guess so - the bottom of my report says "Benchmark built by Ubuntu Security Guide" [11:32] A previous commit mentions a ComplianceAsCode fork too [11:33] yeah, but i thought USG just parsed and formatted it, eg https://github.com/canonical/ubuntu-security-guide/blob/master/tools/extract_rule_yml.py#L19-L22 [11:39] konstruktoid, sbdj we have a private fork of CaC where we store the things that are still to be upstreamed and we are stuck on a frozen version of CaC as upstream moves faster than what we want for usg [11:39] for now only stig is completely upstream [11:43] thanks for the explanation ebarretto [12:11] ebarretto thanks for the info :) [12:47] How can I scan my Ubuntu systems for CVEs (including unpatched ones)? [12:59] luis220413, you can use OVAL for that: https://ubuntu.com/security/oval download the com.ubuntu..cve.oval.xml.bz2 instead [13:05] ebarretto: Thanks [13:28] According to the Tracker, CVE-2022-25235 and CVE-2022-25236 are fixed in Focal and my Ubuntu systems have the fixed version. However, the OpenSCAP result in one of those systems lists that I am vulnerable. [13:28] xmltok_impl.c in Expat (aka libexpat) before 2.4.5 lacks certain validation of encoding, such as checks for whether a UTF-8 character is valid in a certain context. [13:28] xmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to insert namespace-separator characters into namespace URIs. [13:29] s/my Ubuntu systems/my Ubuntu systems running Focal/ [13:29] That (x86_64) system is also marked as being affected by CVE-2022-23960, that only affects ARM processors. [13:29] Certain Arm Cortex and Neoverse processors through 2022-03-08 do not properly restrict cache speculation, aka Spectre-BHB. An attacker can leverage the shared branch history in the Branch History Buffer (BHB) to influence mispredicted branches. Then, cache allocation can allow the attacker to obtain sensitive information. [13:32] luis220413, what is openscap returning? true or false? [13:32] ebarretto: true for these 3 CVEs [13:39] Same for CVE-2022-0847, probably because CVEs for linux-hwe-5.15 are not being tracked (I just reported this by email). [13:39] A flaw was found in the way the "flags" member of the new pipe buffer structure was lacking proper initialization in copy_page_to_iter_pipe and push_pipe functions in the Linux kernel and could thus contain stale values. An unprivileged local user could use this flaw to write to pages in the page cache backed by read only files and as such escalate their privileges on the syste... [13:39] This one is Dirty Pipe [13:40] I'm trying to check here the expat cves [13:41] regarding CVE-2022-23960, we don't make distinction on architecture [13:41] Certain Arm Cortex and Neoverse processors through 2022-03-08 do not properly restrict cache speculation, aka Spectre-BHB. An attacker can leverage the shared branch history in the Branch History Buffer (BHB) to influence mispredicted branches. Then, cache allocation can allow the attacker to obtain sensitive information. [13:48] ebarretto: CVE-2022-23960 is another false positive for Linux. [13:48] Certain Arm Cortex and Neoverse processors through 2022-03-08 do not properly restrict cache speculation, aka Spectre-BHB. An attacker can leverage the shared branch history in the Branch History Buffer (BHB) to influence mispredicted branches. Then, cache allocation can allow the attacker to obtain sensitive information. [13:48] Specifically linux-hwe-5.15 [13:50] luis220413, please don't send emails about things not tracked or about eol release, things will get done when we have the time. Just bear with us please. Kernel CVEs will be tracked by the kernel team, they have their own process for it [14:02] luis220413, can you run your oscap again like the following: oscap oval eval --report report.html --results result.xml --verbose INFO --verbose-log-file log.txt com.ubuntu.focal.cve.oval.xml It is probably returning true for some other package you have installed [14:03] ebarretto: What should I tell you about the run? [14:04] luis220413, can you send me the generated reports by email: eduardo.barretto@canonical.com ? [14:05] That is, report.html, result.xml and log.txt? [14:05] ebarretto: ^ [14:06] luis220413, yes, please [14:12] The attachments are 160 MB combined and the largest is 100 MB. Does your email accept this? [14:12] ebarretto: ^ [14:13] I have not sent you the email yet due to the size of the generated reports. [14:14] ouch, /me forgot how big oval files can be [14:14] luis220413, I will walk you through what you should search in your result.xml if possible [14:14] it will be easier [14:14] ebarretto: Thanks! [14:16] luis220413, in the result.xml search for: 2022252350000000 ... this is the CVE ID in the file, you should find it twice, the first one is the oval definition itself, the second one is what I'm looking for, if you could copy and paste that second definition. It will have results like true and false [14:27] ebarretto: https://paste.gnome.org/0z5hKlpcE [14:30] luis220413, thanks! as I suspected, it is returning true for two packages: firefox and thunderbird, you can verify that by checking the first definition of 2022252350000000, what the ids returning true (2021299550000000 and 2021459600000070) are defined there [14:31] luis220413, and indeed firefox and thunderbird were not patched still for focal [14:33] luis220413, the CVE OVAL is really noisy in that sense, as it will check a lot of things, and the reason why we usually push for usn based oval, as most people want to see what fixes they are missing. So you need to be careful and look through the logs to figure out if you are indeed affected or which package specifically is not yet patched. It might even be that it is a mistake on our side (in the tracker or in the oval file) [15:32] ebarretto: I want (and package) fixes not only from Ubuntu, but from upstream projects, Debian and (possibly but rarely) other sources, as not all CVEs (primarily in Universe but also in Main) are unpatched in Ubuntu. [15:35] Edit: I want to see (and package) missing fixes not only from Ubuntu, but from upstream projects, Debian and (possibly but rarely) other sources, as not all CVEs (primarily in Universe but also in Main) are unpatched in Ubuntu. [15:37] luis220413, cve oval that you are using is the way to go ... or some other vulnerability scanner, there are plenty in the market [15:41] luis220413, I appreciate you interest on helping Ubuntu, but keep in mind the patching vs packaging new versions. Patching is always more welcome than new package version as our goal is to be a stable OS [15:41] safe and stable OS [15:50] ebarretto: How can I get the OVAL report to list the affected packages for each CVE' [15:51] s/'/?/ [15:55] luis220413, I think you would need to write some script to parse the result.xml or maybe there's some vuln scanner out there that does that for you. Maybe someone here has a better advice [19:28] Hey folks, hope you're doing well! I'm looking to write some automation that will report on what security updates are available for packages in our internal apt repos. OpenSCAP is very focused on host-level reporting, and I haven't found any decent OVAL parsing libraries to roll my own. Is there any structured data about Ubuntu security updates other than OVAL? [19:29] Odd_Bloke: apt? Probably that's not what you mean, but in that case, what would you be missing exactly? [19:29] I'd like to know what is being addressed, in terms of CVE/USN, ideally. [19:29] heya Odd_Bloke :) good to see you [19:29] https://git.launchpad.net/ubuntu-cve-tracker/tree maybe? But that might be fun to parse. [19:30] Odd_Bloke: one of our oval sources assumes a list of installed packages in a 'manifest' file, that might be one approach [19:30] Specifically https://git.launchpad.net/ubuntu-cve-tracker/tree/active [19:31] that git repo is another, but anonymous access to it can be very iffy because it's also used as a datasource for this kind of use, and those folks clone or upgrade or whatever way too often .. [19:40] sarnold: That manifest approach sounds promising: how does that work? [19:42] rbasak: Thanks for the pointer to the git repo! That's the sort of thing I was hoping for (though agreed on the parsing looking like Fun, haha). [19:42] Odd_Bloke: grab the "OCI image" version of the oval from https://ubuntu.com/security/oval and feed in a manifest like https://cloud-images.ubuntu.com/releases/focal/release/ubuntu-20.04-server-cloudimg-amd64-root.manifest .. I wouldn't be surprised if we've got a handy dpkg-query command laying around somewhere [19:44] Odd_Bloke: oh, apparently it's got more sharp edges to it than I thought, https://github.com/canonical/sec-cvescan/issues/61 -- maybe best to do some dpkg -l | awk things instead :( [19:44] Issue 61 in canonical/sec-cvescan "Is dpkg-query -W sufficient for the manifest?" [Open] [19:45] (that's a different tool, one I recommend ignoring, but the discussion seems relevant to building the manifest) [19:45] Aha, excellent, that's definitely a promising direction: that's `dpkg-query -W` output (though I think I'll need to generate it myself, as I'm querying apt for the package-versions, not dpkg). [19:46] It sounds like generating a "manifest" containing the latest version of every package in our repos should do the trick (and, ofc, I don't need to worry about uninstalled packages etc.). [19:48] yeah [19:48] The other thing I was going to mention, BTW, is https://ubuntu.com/security/cves?q=&package=&priority=&version=focal&status= has 504'd for me every time I've tried to use it today. I don't particularly need it (certainly not after this assistance), but FYI. [19:49] argh :( [19:49] thanks [19:52] Thank you both for all the help! [20:14] Hacked something together which works! \o/ [20:29] woot! [20:31] sarnold: Can you come to #ubuntu-motu to discuss a security update for Tor? [20:35] omg there's *more* irc channels I'm not already in? I didn't thikn it possible