Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.