> On 07/07/2022 23:59 EEST Noel Butler <noel.but...@ausics.net> wrote: > > > On 07/07/2022 07:24, Aki Tuomi wrote: > > > > > > > On 06/07/2022 16:54 EEST Aki Tuomi via Dovecot-news > > > <dovecot-n...@dovecot.org> wrote: > > > > > > > > > Affected product: Dovecot IMAP Server > > > Internal reference: DOV-5320 > > > Vulnerability type: Improper Access Control (CWE-284) > > > Vulnerable version: 2.2 > > > Vulnerable component: submission > > > Report confidence: Confirmed > > > Solution status: Fixed in main > > > Researcher credits: Julian Brook (julezman) > > > Vendor notification: 2022-05-06 > > > CVE reference: CVE-2022-30550 > > > CVSS: 6.8 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) > > > > > > Vulnerability Details: > > > When two passdb configuration entries exist in Dovecot configuration, > > > which have the same driver and args settings, the incorrect > > > username_filter and mechanism settings can be applied to passdb > > > definitions. These incorrectly applied settings can lead to an unintended > > > security configuration and can permit privilege escalation with certain > > > configurations involving master user authentication. > > > > > > Dovecot documentation does not advise against the use of passdb > > > definitions which have the same driver and args settings. One such > > > configuration would be where an administrator wishes to use the same pam > > > configuration or passwd file for both normal and master users but use the > > > username_filter setting to restrict which of the users is able to be a > > > master user. > > > > > > Risk: > > > If same passwd file or PAM is used for both normal and master users, it > > > is possible for attacker to become master user. > > > > > > Workaround: > > > Always authenticate master users from different source than regular > > > users, e.g. using a separate passwd file. Alternatively, you can use > > > global ACLs to ensure that only legimate master users have priviledged > > > access. > > > > > > Fix: > > > This has been fixed in main branch. See > > > https://github.com/dovecot/core/compare/7bad6a24%5E..a1022072.patch > > > > Two small corrections to this CVE notice... The service impacted is of > > course 'auth' not 'submission', and the version impacted is from 2.2 to > > 2.3.19.1. > > > > Aki > > I wouldnt exactly call them " small " corrections > its like saying the left window on your 2020 car can be pushed down easily to > saying oh wait its every window and you dont need a key to start the engine > and btw its all cars from 2010 to 2022 > > And if its that serious where is the release, thats how dealing with CVE's > works Aki, not a CVE statement saying go to gitbub. > That said, I'd assume everyone uses a separate db for support teams anyway, > or I'd hope so/ > > -- > > Regards, > Noel Butler
Not all CVEs are "that serious". CVE scores are problematic, you can have a solid 10.0 CVE score that affects practically no one, and you can have a 3.8 CVE that affects ~everyone using the software. This particular bug requires a quite specific setup, and also provides a sensible workaround for it. It will be included in upcoming 2.4 release, we do not currently see any pressing reason to rush out a CVE patch release for this. Aki
