Bug 1399841 - Remote command execution allows integers outside 32 bit range
Summary: Remote command execution allows integers outside 32 bit range
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: WebUI
Version: 570
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Jiří Dostál
QA Contact: Pavel Studeník
URL:
Whiteboard:
Depends On:
Blocks: 465198 sat580-low
TreeView+ depends on / blocked
 
Reported: 2016-11-29 21:24 UTC by Shannon Hughes
Modified: 2020-07-16 09:02 UTC (History)
5 users (show)

Fixed In Version: spacewalk-java-2.5.14-49-sat
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-21 12:09:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch to add validation to remote command timeout field (4.09 KB, patch)
2016-12-01 01:07 UTC, Shannon Hughes
no flags Details | Diff

Description Shannon Hughes 2016-11-29 21:24:14 UTC
Description of problem:

When scheduling a remote command, the Satellite webui allows integers outside a 32 bit range which gives the XMLRPC api run throw stack traces due to out of range during the remote command pickup by rhn_check, 

Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/spacewalk/server/apacheRequest.py", line 122, in call_function
    response = func(*params)
  File "/usr/share/rhn/server/handlers/xmlrpc/queue.py", line 354, in get
    ret = self.__getV2(action)
  File "/usr/share/rhn/server/handlers/xmlrpc/queue.py", line 95, in __getV2
    xmlblob = xmlrpclib.dumps(result, methodname=action['method'])
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1132, in dumps
    data = m.dumps(params)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 677, in dumps
    dump(v, write)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 699, in __dump
    f(self, value, write)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 780, in dump_struct
    dump(v, write)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 699, in __dump
    f(self, value, write)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 710, in dump_int
    raise OverflowError, "int exceeds XML-RPC limits"
OverflowError: int exceeds XML-RPC limits


Frame dump_int in /usr/lib64/python2.6/xmlrpclib.py at line 710
	               write = <type 'builtin_function_or_method'> <built-in method append of list object at 0x7fb742454c20>
	                self = <type 'instance'> <xmlrpclib.Marshaller instance at 0x7fb742ca1c68>
	               value = <type 'int'> 6000000000

Frame __dump in /usr/lib64/python2.6/xmlrpclib.py at line 699
	               write = <type 'builtin_function_or_method'> <built-in method append of list object at 0x7fb742454c20>
	                self = <type 'instance'> <xmlrpclib.Marshaller instance at 0x7fb742ca1c68>
	               value = <type 'int'> 6000000000
	                   f = <type 'function'> <function dump_int at 0x7fb742538938>

Frame dump_struct in /usr/lib64/python2.6/xmlrpclib.py at line 780
	                dump = <type 'instancemethod'> <bound method Marshaller.__dump of <xmlrpclib.Marshaller instance at 0x7fb742ca1c68>>
	                   i = <type 'int'> 140425077837632
	                   k = <type 'str'> timeout
	                   v = <type 'int'> 6000000000
	               value = <type 'dict'> {'username': 'root', 'groupname': 'root', 'now': '2016-11-29 16:01:39', 'timeout': 6000000000, 'script': '#!/bin/sh\r\necho "Time: $(date)" >> /tmp/foobar'}
	               write = <type 'builtin_function_or_method'> <built-in method append of list object at 0x7fb742454c20>
	              escape = <type 'function'> <function escape at 0x7fb742504668>
	                self = <type 'instance'> <xmlrpclib.Marshaller instance at 0x7fb742ca1c68>



Steps to Reproduce:
1. create remote command for system using rhncfg 
2. set timeout value to 6000000000
3. run rhn_check -vvvv on client
4. 500 is thrown, check the traceback email

We need to add validation check to take in max  2,147,483,647 value

Comment 1 Shannon Hughes 2016-11-30 14:14:05 UTC
Did some more research on this issue and have found that the timeout value is also overflowing in the database when using the api to access the values: 

[shughes@workerbee scripts]$ perl foo.pl 
$VAR1 = {
          'id' => '28582',
          'result' => [],
          'timeout' => '-589934592',
          'run_as_user' => 'root',
          'run_as_group' => 'root',
          'content' => '#!/bin/sh
echo "foobar"
'
        };
$VAR1 = {
          'content' => '#!/bin/sh
echo \'nothing to do here\'
',
          'run_as_group' => 'root',
          'run_as_user' => 'root',
          'timeout' => '1705032704',
          'id' => '28581',
          'result' => []
        };

The -589934592 value looks like an overflow for a value of 8,000,000,000 that was entered into the webui remote command timeout field. The 1705032704 value represents a value of 6,000,000,000 that was entered in webui timeout field. When viewing the action in the webui though the original values are showing correctly. In summary, I don't think we can just validate on the max XMLRPC integer until we review the tables that are holding the timeout values. That will be my next step in research.

Comment 2 Shannon Hughes 2016-11-30 15:04:21 UTC
looks like the xmlrpc layer is rolling over when you cross 2^32 -1 (2147483647). The database is preserving the large numbers. 

So a value of 2147483648 becomes -2147483648 since it rolls over the signed integer range of -2147483648 to 2147483647

Comment 3 Shannon Hughes 2016-12-01 01:07:59 UTC
Created attachment 1226568 [details]
patch to add validation to remote command timeout field

patch to add validation to the remote command page for the timeout value.

Comment 6 Jiří Dostál 2016-12-07 13:36:36 UTC
I reviewed the patch and with minor modifications pushed to spacewalk.

spacewalk 5dc926c80fc265fee5e6ce6ceb6c84c5f89fadf3

Comment 8 Pavel Studeník 2017-05-19 12:25:10 UTC
Verified with spacewalk-java-2.5.14-84.el6sat.noarch

warning alert: "Timeout value specified exceeds max value of 2147483647."


Note You need to log in before you can comment on or make changes to this bug.