|
Message-ID: <20240802145338.GA12405@openwall.com> Date: Fri, 2 Aug 2024 16:53:38 +0200 From: Solar Designer <solar@...nwall.com> To: Dane Bouchie <dbouchie@...dimed.com> Cc: Andri Yngvason <andri@...vason.is>, "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>, Travis Wise <travis@...esquared.com>, "security@...pberrypi.com" <security@...pberrypi.com>, Simon Long <simon@...pberrypi.com>, Moritz M??hlenhoff <jmm@...til.org>, Salvatore Bonaccorso <carnil@...ian.org> Subject: Re: Neat VNC Security Vulnerability On Fri, Aug 02, 2024 at 02:41:18PM +0000, Dane Bouchie wrote: > The client chooses the security type, so they can pass in "None" to the switch statement. is_allowed_security_type() now prevents that. Oh, so was the issue a trivial authentication bypass? Evidently, logic errors like this are easy to miss in plain sight. switch (type) { case RFB_SECURITY_TYPE_NONE: security_handshake_ok(client, NULL); client->state = VNC_CLIENT_STATE_WAITING_FOR_INIT; break; Should the above RFB_SECURITY_TYPE_NONE support continue to exist in the code at all, if RFB_SECURITY_TYPE_NONE is never added to the allowed security types array that the code now pre-checks against? Maybe it should be #if 0'ed out, leaving it only as an example for debugging? Thank you for the extremely prompt response. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.