diff mbox series

[XENSTORE,v1,06/10] xenstored: handle port reads correctly

Message ID 20210226144144.9252-7-nmanthey@amazon.de (mailing list archive)
State New
Headers show
Series Code analysis fixes | expand

Commit Message

Norbert Manthey Feb. 26, 2021, 2:41 p.m. UTC
The read value could be larger than a signed 32bit integer. As -1 is
used as error value, we should not rely on using the full 32 bits.
Hence, when reading the port number, we should make sure we only return
valid values.

This change sanity checks the input.
The issue is that the value for the port is
 1. transmitted as a string, with a fixed amount of digits.
 2. Next, this string is parsed by a function that can deal with strings
    representing 64bit integers
 3. A 64bit integer is returned, and will be truncated to it's lower
    32bits, resulting in a wrong port number (in case the sender of the
    string decides to craft a suitable 64bit value).

The value is typically provided by the kernel, which has this value hard
coded in the proper range. As we use the function strtoul, non-digit
character are considered as end of the input, and hence do not require
checking. Therefore, this change only covers the corner case to make
sure we stay in the 32 bit range.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.

Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
Reviewed-by: Thomas Friebel <friebelt@amazon.de>
Reviewed-by: Julien Grall <jgrall@amazon.co.uk>

---
 tools/xenstore/xenstored_posix.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Comments

Andrew Cooper Feb. 26, 2021, 3:36 p.m. UTC | #1
On 26/02/2021 14:41, Norbert Manthey wrote:
> The read value could be larger than a signed 32bit integer. As -1 is
> used as error value, we should not rely on using the full 32 bits.
> Hence, when reading the port number, we should make sure we only return
> valid values.
>
> This change sanity checks the input.
> The issue is that the value for the port is
>  1. transmitted as a string, with a fixed amount of digits.
>  2. Next, this string is parsed by a function that can deal with strings
>     representing 64bit integers
>  3. A 64bit integer is returned, and will be truncated to it's lower
>     32bits, resulting in a wrong port number (in case the sender of the
>     string decides to craft a suitable 64bit value).
>
> The value is typically provided by the kernel, which has this value hard
> coded in the proper range. As we use the function strtoul, non-digit
> character are considered as end of the input, and hence do not require
> checking. Therefore, this change only covers the corner case to make
> sure we stay in the 32 bit range.
>
> This bug was discovered and resolved using Coverity Static Analysis
> Security Testing (SAST) by Synopsys, Inc.
>
> Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
> Reviewed-by: Thomas Friebel <friebelt@amazon.de>
> Reviewed-by: Julien Grall <jgrall@amazon.co.uk>

Port numbers are currently limited at 2^17, with easy extension to 2^29
(iirc), but the entire event channel infrastructure would have to
undergo another redesign to get beyond that.

I think we can reasonably make an ABI statement saying that a port
number will never exceed 2^31.  This is already pseudo-encoded in the
evtchn_port_or_error_t mouthful.

~Andrew
Juergen Gross March 2, 2021, 5:15 a.m. UTC | #2
On 26.02.21 16:36, Andrew Cooper wrote:
> On 26/02/2021 14:41, Norbert Manthey wrote:
>> The read value could be larger than a signed 32bit integer. As -1 is
>> used as error value, we should not rely on using the full 32 bits.
>> Hence, when reading the port number, we should make sure we only return
>> valid values.
>>
>> This change sanity checks the input.
>> The issue is that the value for the port is
>>   1. transmitted as a string, with a fixed amount of digits.
>>   2. Next, this string is parsed by a function that can deal with strings
>>      representing 64bit integers
>>   3. A 64bit integer is returned, and will be truncated to it's lower
>>      32bits, resulting in a wrong port number (in case the sender of the
>>      string decides to craft a suitable 64bit value).
>>
>> The value is typically provided by the kernel, which has this value hard
>> coded in the proper range. As we use the function strtoul, non-digit
>> character are considered as end of the input, and hence do not require
>> checking. Therefore, this change only covers the corner case to make
>> sure we stay in the 32 bit range.
>>
>> This bug was discovered and resolved using Coverity Static Analysis
>> Security Testing (SAST) by Synopsys, Inc.
>>
>> Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
>> Reviewed-by: Thomas Friebel <friebelt@amazon.de>
>> Reviewed-by: Julien Grall <jgrall@amazon.co.uk>
> 
> Port numbers are currently limited at 2^17, with easy extension to 2^29
> (iirc), but the entire event channel infrastructure would have to
> undergo another redesign to get beyond that.
> 
> I think we can reasonably make an ABI statement saying that a port
> number will never exceed 2^31.  This is already pseudo-encoded in the
> evtchn_port_or_error_t mouthful.

I agree. There is no need for this patch.


Juergen
Norbert Manthey March 2, 2021, 7:48 a.m. UTC | #3
On 3/2/21 6:15 AM, Jürgen Groß wrote:
> On 26.02.21 16:36, Andrew Cooper wrote:
>> On 26/02/2021 14:41, Norbert Manthey wrote:
>>> The read value could be larger than a signed 32bit integer. As -1 is
>>> used as error value, we should not rely on using the full 32 bits.
>>> Hence, when reading the port number, we should make sure we only return
>>> valid values.
>>>
>>> This change sanity checks the input.
>>> The issue is that the value for the port is
>>>   1. transmitted as a string, with a fixed amount of digits.
>>>   2. Next, this string is parsed by a function that can deal with
>>> strings
>>>      representing 64bit integers
>>>   3. A 64bit integer is returned, and will be truncated to it's lower
>>>      32bits, resulting in a wrong port number (in case the sender of
>>> the
>>>      string decides to craft a suitable 64bit value).
>>>
>>> The value is typically provided by the kernel, which has this value
>>> hard
>>> coded in the proper range. As we use the function strtoul, non-digit
>>> character are considered as end of the input, and hence do not require
>>> checking. Therefore, this change only covers the corner case to make
>>> sure we stay in the 32 bit range.
>>>
>>> This bug was discovered and resolved using Coverity Static Analysis
>>> Security Testing (SAST) by Synopsys, Inc.
>>>
>>> Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
>>> Reviewed-by: Thomas Friebel <friebelt@amazon.de>
>>> Reviewed-by: Julien Grall <jgrall@amazon.co.uk>
>>
>> Port numbers are currently limited at 2^17, with easy extension to 2^29
>> (iirc), but the entire event channel infrastructure would have to
>> undergo another redesign to get beyond that.
>>
>> I think we can reasonably make an ABI statement saying that a port
>> number will never exceed 2^31.  This is already pseudo-encoded in the
>> evtchn_port_or_error_t mouthful.
>
> I agree. There is no need for this patch.

I understand, and am fine with dropping this patch.

Out of curiosity, if the actual limit is lower than what the patch
currently enforces, would it make sense to adapt the bound check to that
number?

Best,
Norbert

>
>
> Juergen
>




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
Juergen Gross March 2, 2021, 8:12 a.m. UTC | #4
On 02.03.21 08:48, Norbert Manthey wrote:
> On 3/2/21 6:15 AM, Jürgen Groß wrote:
>> On 26.02.21 16:36, Andrew Cooper wrote:
>>> On 26/02/2021 14:41, Norbert Manthey wrote:
>>>> The read value could be larger than a signed 32bit integer. As -1 is
>>>> used as error value, we should not rely on using the full 32 bits.
>>>> Hence, when reading the port number, we should make sure we only return
>>>> valid values.
>>>>
>>>> This change sanity checks the input.
>>>> The issue is that the value for the port is
>>>>    1. transmitted as a string, with a fixed amount of digits.
>>>>    2. Next, this string is parsed by a function that can deal with
>>>> strings
>>>>       representing 64bit integers
>>>>    3. A 64bit integer is returned, and will be truncated to it's lower
>>>>       32bits, resulting in a wrong port number (in case the sender of
>>>> the
>>>>       string decides to craft a suitable 64bit value).
>>>>
>>>> The value is typically provided by the kernel, which has this value
>>>> hard
>>>> coded in the proper range. As we use the function strtoul, non-digit
>>>> character are considered as end of the input, and hence do not require
>>>> checking. Therefore, this change only covers the corner case to make
>>>> sure we stay in the 32 bit range.
>>>>
>>>> This bug was discovered and resolved using Coverity Static Analysis
>>>> Security Testing (SAST) by Synopsys, Inc.
>>>>
>>>> Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
>>>> Reviewed-by: Thomas Friebel <friebelt@amazon.de>
>>>> Reviewed-by: Julien Grall <jgrall@amazon.co.uk>
>>>
>>> Port numbers are currently limited at 2^17, with easy extension to 2^29
>>> (iirc), but the entire event channel infrastructure would have to
>>> undergo another redesign to get beyond that.
>>>
>>> I think we can reasonably make an ABI statement saying that a port
>>> number will never exceed 2^31.  This is already pseudo-encoded in the
>>> evtchn_port_or_error_t mouthful.
>>
>> I agree. There is no need for this patch.
> 
> I understand, and am fine with dropping this patch.
> 
> Out of curiosity, if the actual limit is lower than what the patch
> currently enforces, would it make sense to adapt the bound check to that
> number?

No, I don't think so. Especially as the boundary to check against isn't
known by Xenstore (the boundary value depends on 2-level or fifo events
being used, and this information is not exported to user land).

The value is coming from the kernel, and it is used with another kernel
interface. So if the kernel wants to play dirty tricks with Xenstore, it
doesn't need to deliver a wrong event channel number, it can just play
those games in the event channel driver.


Juergen
diff mbox series

Patch

diff --git a/tools/xenstore/xenstored_posix.c b/tools/xenstore/xenstored_posix.c
--- a/tools/xenstore/xenstored_posix.c
+++ b/tools/xenstore/xenstored_posix.c
@@ -116,7 +116,7 @@  evtchn_port_t xenbus_evtchn(void)
 {
 	int fd;
 	int rc;
-	evtchn_port_t port;
+	uint64_t port;
 	char str[20];
 
 	fd = open(XENSTORED_PORT_DEV, O_RDONLY);
@@ -136,6 +136,10 @@  evtchn_port_t xenbus_evtchn(void)
 	port = strtoul(str, NULL, 0);
 
 	close(fd);
+
+	if (port >= UINT32_MAX)
+		return -1;
+
 	return port;
 }