[ZBX-9682] parameters with leading zeros and trailing symbols can be treated as valid numerical parameters Created: 2015 Jul 07  Updated: 2017 May 30  Resolved: 2015 Aug 30

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Agent (G), Proxy (P), Server (S)
Affects Version/s: 2.4.5
Fix Version/s: 2.2.11rc1, 2.4.7rc1, 3.0.0alpha2

Type: Incident report Priority: Minor
Reporter: Glebs Ivanovskis (Inactive) Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: items, validation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For example command

zabbix_agentd -t 'vfs.file.regexp[/tmp/a,Ubuntu,,000000000000000000001ajhjahgkga]'

does not fail and produce the same result as

zabbix_agentd -t 'vfs.file.regexp[/tmp/a,Ubuntu,,1]'

File /tmp/a contains line "Ubuntu 14.02 LTS" followed by new line.

This is probably a more general issue not restricted to agent or this particular function.



 Comments   
Comment by richlv [ 2015 Jul 07 ]

i'm not sure about this. something like that is highly likely to be caused by an error (let's say, user mixing up parameters places in their api script, or having a typo).
strict validation would be more preferred here.
also imagine somebody typing "3m" in a parameter - it would be very hard to be sure what the end result would be, confusion galore.

leading zeros could be considered, though

edit: oh, wait. this issue actually says that the agent actually accepts that, my bad

Comment by Glebs Ivanovskis (Inactive) [ 2015 Jul 07 ]

In function is_uint_n_range() (src/libs/zbxcommon/misc.c): isdigit('0') is true, therefore leading zeros are valid. If there are enough leading zeros there will be no uint64/32/31... overflow and function will stop reading string because it assumes it has enough digits already. Any rubbish can be passed afterwards without any error messages.

Comment by Igors Homjakovs (Inactive) [ 2015 Jul 08 ]

Fix for version 2.2 is available in svn://svn.zabbix.com/branches/dev/ZBX-9682

Version 2.0 is not affected.

Comment by Andris Zeila [ 2015 Jul 29 ]

(1) The problem with the fix is when parsing out values from a string.

For example we have a string [first,0002,third]. A parser finds the start and end of the second parameter and tries to convert its value to integer. So it will call

is_uint_n_range(<pointer to first zero>, 4, <pointer to output buffer> (size_t)8, 0x0LL, 0xFFFFFFFFFFFFFFFFLL)

Now the is_uint_n_range() function will skip the leading zeroes, try to convert "2,th" to integer value and fail.

Instead of manually skipping leading zeroes it would be better to change is_uint definitions in common.h to use maximum size_t value instead of ZBX_MAX_UINT64_LEN when the string is assumed to be zero terminated. For example something like:

#define SIZE_T_MAX	(~(size_t)0)

#define is_ushort(str, value) \
	is_uint_n_range(str, (size_t)SIZE_T_MAX, value, sizeof(unsigned short), 0x0LL, 0xFFFFLL)

igorsh RESOLVED in r54632.

wiper CLOSED

Comment by Andris Zeila [ 2015 Jul 31 ]

Successfully tested

Comment by Alexander Vladishev [ 2015 Aug 30 ]

Fixed in

  • pre-2.2.11 r55256
  • pre-2.4.7 r55257
  • pre-3.0.0alpha2 (trunk) r55258
Generated at Thu Mar 28 21:53:03 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.