[01:43] <teward> sdeziel: so fyi "public mirrors" end up in the country RRs.  So even if you're in {CC}.archive.ubuntu.com you end up being put through the pool.  Hence security.ubuntu.com as the default
[01:43] <teward> just to echo mdeslaur and others
[01:43] <teward> it's soemthing that's been that way forever, as the Mirrors team (not Security) explained initally
[01:44] <teward> (back when I did regular mirroring)
[19:35] <tommyfun> hey
[19:36] <tommyfun> I keep my ubuntu servers patched nightly with the unattended upgrades
[19:36] <tommyfun> the security team at my org scanned my 20.04 servers and triggered an alert that apache2 was insecure
[19:37] <tommyfun> but it's the latest one
[19:37] <tommyfun> they use nessus
[19:38] <tommyfun> if I put the latest apache2 dpkg on, will it fuck it up somehow?  break dependancies? not be upgradeable with unattended-upgrades?
[19:38] <arraybolt3> apache2 is in the Main repository, if you keep your system up-to-date you should be good.
[19:38] <arraybolt3> I'd run "sudo apt update && sudo apt full-upgrade" to be sure.
[19:38] <tommyfun> Or should I trust the security updates and tell them to kick rocks
[19:38] <arraybolt3> Security scanners are notoriously bad at scanning Ubuntu.
[19:38] <arraybolt3> They seem to scan the version numbers to check for vulns.
[19:38] <tommyfun> thanks
[19:38] <arraybolt3> Ubuntu uses old versions of software and backports fixes as needed.
[19:39] <arraybolt3> So the version numbers *look* insecure to some scanners, even though the vulns are fixed.
[19:39] <arraybolt3> You can use security.ubuntu.com to look up Ubuntu Security Notices to ensure that certain CVEs are patched.
[19:41] <tomreyn> yes, it can depend on how nessus determines the versions. they support two approaches - network scans (from external) or agent based (running on the system). the latter can make use of information provided by dpkg, such as which actual pakcage version is installed. whereas network scanning may only see the version the serive (apache) exposes, which is often just the base version, not providing information on which security patches were 
[19:41] <tomreyn> applied.
[19:43] <tomreyn> serive -> service
[19:43] <arraybolt3> Oddly, though, security.ubuntu.com seems to be possibly missing some CVE info? For instance, I can see that apache2 isn't vulnerable to CVE-2022-23943 looking at Debian's security tracker and comparing the version numbers there to the version number in Ubuntu 22.10... but I can't find said CVE in the Ubuntu Security Notice list.
[19:43] -ubottu:#ubuntu-security- Out-of-bounds Write vulnerability in mod_sed of Apache HTTP Server allows an attacker to overwrite heap memory with possibly attacker provided data. This issue affects Apache HTTP Server 2.4 version 2.4.52 and prior versions. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23943>
[19:43] <sdeziel> to avoid tripping version sniffers, you can tell Apache2 to disclose less with `ServerTokens Prod` and `ServerSignature Off`
[19:44] <tommyfun> yeah, I had the security.conf settings not to disclode anything but I thought that this might be the issue, becasue it can't tell
[19:44] <arraybolt3> Oh wait, now I found it.
[19:45] <arraybolt3> Meh. Wonder why I didn't find it at first.
[19:46] <tommyfun> One of the issues is/was with mod proxy, but I'm not even running it, my boss doesn't want their nessus agent on the server, but I don't have time to deal with these false positives
[19:47] <arraybolt3> tomreyn: Isn't there some sort of security scanner for Ubuntu specifically that Canonical has, something about OPAL or some such?
[19:47] <arraybolt3> *OVAL
[19:47] <arraybolt3> https://ubuntu.com/security/oval
[19:47] <arraybolt3> Found it.
[19:48] <tommyfun> I don't know.  Both of you have helped me enough.
[19:48] <tomreyn> arraybolt3: i'm not aware of Canonical producing a vulnerability scanner specifically for Ubuntu
[19:48] <tommyfun> thanks
[19:48] <tomreyn> tommyfun: what's the report you've been given?
[19:48] <arraybolt3> It wasn't a scanner, it's data *for* a scanner.
[19:48] <tommyfun> it was a nessus report
[19:49] <tomreyn> tommyfun: and the very finding is?
[19:49] <arraybolt3> Not sure if you can afford to uproot whatever you're using and try and use OpenSCAP, and I don't know enough to know if that's even a good idea or if the two are the same thing or close, but from what I've gleaned here, that might be useful.
[19:50] <tommyfun> sorry it's tenable
[19:50] <arraybolt3> tommyfun: I think he wants to know so that he can show the corresponding Ubuntu Security Notice.
[19:50] <arraybolt3> But you should be able to just plug in whatever CVE number it spit out into the USN database and it will tell you what update fixes it.
[19:50] <tommyfun> Apache 2.4.x < 2.4.55 Multiple Vulnerabilities: Upgrade to Apache version 2.4.55 or later.
[19:51] <tomreyn> this very finding you should be able to get rid of by using what sdeziel suggested
[19:52] <arraybolt3> I see there are vuln-patching updates as early as 1 February here https://ubuntu.com/security/notices/USN-5839-1
[19:52] <tommyfun> yeah, I was looking at that feb 1 notice
[19:53] <tommyfun> so if I installed the latest dpkg manually, does that break anything?
[19:53] <arraybolt3> You might break stuff installing things with dpkg. It should never be used manually except in exceptional circumstances.
[19:54] <arraybolt3> apt can apply updates safely and easily.
[19:54] <tommyfun> yeah, that's what I thought.
[19:54] <tommyfun> I could build a vm and test it, maybe later
[19:54] <tommyfun> thanks for all your help
[19:55] <tomreyn> this approach won't solve the issue for you in the long term
[19:55] <arraybolt3> tommyfun: If you're trying to only selectively patch just Apache, you can do that with apt.
[19:56] <arraybolt3> "sudo apt update && sudo apt install apache2" will update only just Apache and anything that needs to be updated in order for Apache to be updated.
[19:56] <tomreyn> there is something else you need to know, which is that while unattended-upgrades will update and reload affected services automatically, libraries may not immediately get updated, if they are still in use. but, based on the finding given, that's probbaly not what's happening here.
[20:00] <tomreyn> https://www.tenable.com/plugins/nessus/170113 -> the relevant info is "Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number."