Quantcast

Proper handling and specification of DWORD/QWORD values

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proper handling and specification of DWORD/QWORD values

Shane Shaffer
Improper handling of DWORD data types in OVAL interpreters has long been an issue, though perhaps not a well known issue. Content developers have had to work around this, having to do things like seen in oval:gov.nist.usgcb.windowsseven:def:1 in the USGCB content. This issue appears to be popping up more and more frequently, so let's formally address the problem.

What is the issue exactly? Many interpreters are treating DWORDs as signed integers, which is incorrect. DWORDs are unsigned. The value of a DWORD may be from 0 to 4294967295, but many interpreters will return negative values once they hit 2^16. Failure to properly handle DWORD value leads to situations like in the USGCB definition above, where we have to check for the proper unsigned value (4294967295) and the improper signed value (-1).

Several months ago MITRE addressed this in OVALDI, at least for the case of registry values (http://sourceforge.net/tracker/index.php?func=detail&aid=3462562&group_id=215469&atid=1033794) - I don't know if the fix applied elsewhere). Though the registry is where DWORDs are most common, they do appear in other places, such as the lockoutpolicy object/state used in the referenced USGCB definition. Other OVAL scanner/interpreter developers/vendors - please make sure your tools handle DWORDs/QWORDs properly everywhere that they occur.

From a specification standpoint, it looks like we need to be a bit more precise to eliminate any confusion.  Looking at the OVAL schemas and Windows component specification there is no mention of these being unsigned values. All documentation of the data types currently describe DWORDs as 32 bit integers, and QWORDs as 64 bit integers. That should be amended in the next release, but I don't believe imprecise documentation is a valid excuse for interpreters to misrepresent the data.

Would it make sense to go farther and change the datatypes used by elements representing DWORD/QWORD values? In the case of registry state values, a datatype more precise than the current int would be preferable. Ideally there would also be Schematron validation of the value vs. the datatype, for all legal types, but I don't know how practical that is to implement. For other instances, where there is an explicit datatype on the element, more stringent types could be used. This would require the addition of something like an EntityStateUnsignedIntType, based on xml:unsignedInt, for DWORDs. For QWORDs we would want something like EntityStateUnsignedLongType, based on xml:unsignedLong, though there are currently no instances where this would be used. Or perhaps just a more generic type based on xml:nonNegativeInteger would work for these elements, if we weren't concerned with constraining the max values (which isn't done today).  Changing these types would cause a large amount of content to be trivially updated, but I think the clarity in the definitions is worth it.


Shane Shaffer
Technical Director, Security Automation
G2, Inc.




To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper handling and specification of DWORD/QWORD values

joval
Hi Shane,

I think just a documentation change should be sufficient.  Do you have an OVAL definition file handy that can be used to specifically test for this issue?  Such a test should be added to the test content file, win-def_registry_test.xml.

Regards,
--David

On 4/4/2012 11:21 AM, Shane Shaffer wrote:
Improper handling of DWORD data types in OVAL interpreters has long been an issue, though perhaps not a well known issue. Content developers have had to work around this, having to do things like seen in oval:gov.nist.usgcb.windowsseven:def:1 in the USGCB content. This issue appears to be popping up more and more frequently, so let's formally address the problem.

What is the issue exactly? Many interpreters are treating DWORDs as signed integers, which is incorrect. DWORDs are unsigned. The value of a DWORD may be from 0 to 4294967295, but many interpreters will return negative values once they hit 2^16. Failure to properly handle DWORD value leads to situations like in the USGCB definition above, where we have to check for the proper unsigned value (4294967295) and the improper signed value (-1).

Several months ago MITRE addressed this in OVALDI, at least for the case of registry values (http://sourceforge.net/tracker/index.php?func=detail&aid=3462562&group_id=215469&atid=1033794) - I don't know if the fix applied elsewhere). Though the registry is where DWORDs are most common, they do appear in other places, such as the lockoutpolicy object/state used in the referenced USGCB definition. Other OVAL scanner/interpreter developers/vendors - please make sure your tools handle DWORDs/QWORDs properly everywhere that they occur.

From a specification standpoint, it looks like we need to be a bit more precise to eliminate any confusion.  Looking at the OVAL schemas and Windows component specification there is no mention of these being unsigned values. All documentation of the data types currently describe DWORDs as 32 bit integers, and QWORDs as 64 bit integers. That should be amended in the next release, but I don't believe imprecise documentation is a valid excuse for interpreters to misrepresent the data.

Would it make sense to go farther and change the datatypes used by elements representing DWORD/QWORD values? In the case of registry state values, a datatype more precise than the current int would be preferable. Ideally there would also be Schematron validation of the value vs. the datatype, for all legal types, but I don't know how practical that is to implement. For other instances, where there is an explicit datatype on the element, more stringent types could be used. This would require the addition of something like an EntityStateUnsignedIntType, based on xml:unsignedInt, for DWORDs. For QWORDs we would want something like EntityStateUnsignedLongType, based on xml:unsignedLong, though there are currently no instances where this would be used. Or perhaps just a more generic type based on xml:nonNegativeInteger would work for these elements, if we weren't concerned with constraining the max values (which isn't done today).  Changing these types would cause a large amount of content to be trivially updated, but I think the clarity in the definitions is worth it.


Shane Shaffer
Technical Director, Security Automation
G2, Inc.




To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper handling and specification of DWORD/QWORD values

Kent Landfield
Hi Shane,

I agree with David's approach.  It might also be useful to forward this to the NIST SCAP Validation team so they could include it in the content test suite they distribute to the testing labs for validation testing… That might get things fixed faster. ;-)

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: David Solin <[hidden email]>
Reply-To: "OVAL Developer List (Closed Public Discussion)" <[hidden email]>
Date: Wed, 4 Apr 2012 12:54:57 -0500
To: "[hidden email]" <[hidden email]>
Subject: Re: [OVAL-DEVELOPER-LIST] Proper handling and specification of DWORD/QWORD values

Hi Shane,

I think just a documentation change should be sufficient.  Do you have an OVAL definition file handy that can be used to specifically test for this issue?  Such a test should be added to the test content file, win-def_registry_test.xml.

Regards,
--David

On 4/4/2012 11:21 AM, Shane Shaffer wrote:
Improper handling of DWORD data types in OVAL interpreters has long been an issue, though perhaps not a well known issue. Content developers have had to work around this, having to do things like seen in oval:gov.nist.usgcb.windowsseven:def:1 in the USGCB content. This issue appears to be popping up more and more frequently, so let's formally address the problem.

What is the issue exactly? Many interpreters are treating DWORDs as signed integers, which is incorrect. DWORDs are unsigned. The value of a DWORD may be from 0 to 4294967295, but many interpreters will return negative values once they hit 2^16. Failure to properly handle DWORD value leads to situations like in the USGCB definition above, where we have to check for the proper unsigned value (4294967295) and the improper signed value (-1).

Several months ago MITRE addressed this in OVALDI, at least for the case of registry values (http://sourceforge.net/tracker/index.php?func=detail&aid=3462562&group_id=215469&atid=1033794) - I don't know if the fix applied elsewhere). Though the registry is where DWORDs are most common, they do appear in other places, such as the lockoutpolicy object/state used in the referenced USGCB definition. Other OVAL scanner/interpreter developers/vendors - please make sure your tools handle DWORDs/QWORDs properly everywhere that they occur.

From a specification standpoint, it looks like we need to be a bit more precise to eliminate any confusion.  Looking at the OVAL schemas and Windows component specification there is no mention of these being unsigned values. All documentation of the data types currently describe DWORDs as 32 bit integers, and QWORDs as 64 bit integers. That should be amended in the next release, but I don't believe imprecise documentation is a valid excuse for interpreters to misrepresent the data.

Would it make sense to go farther and change the datatypes used by elements representing DWORD/QWORD values? In the case of registry state values, a datatype more precise than the current int would be preferable. Ideally there would also be Schematron validation of the value vs. the datatype, for all legal types, but I don't know how practical that is to implement. For other instances, where there is an explicit datatype on the element, more stringent types could be used. This would require the addition of something like an EntityStateUnsignedIntType, based on xml:unsignedInt, for DWORDs. For QWORDs we would want something like EntityStateUnsignedLongType, based on xml:unsignedLong, though there are currently no instances where this would be used. Or perhaps just a more generic type based on xml:nonNegativeInteger would work for these elements, if we weren't concerned with constraining the max values (which isn't done today).  Changing these types would cause a large amount of content to be trivially updated, but I think the clarity in the definitions is worth it.


Shane Shaffer
Technical Director, Security Automation
G2, Inc.




To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper handling and specification of DWORD/QWORD values

Danny Haynes
Administrator

I know we had an issue in both the registry_test (value entity) as Shane pointed out and the passwordpolicy_test (max_passwd_age).  We have since added functionality to the OVAL Interpreter so that it performs type-safe conversions of values to strings.  However, we haven’t gone through the entire codebase to make sure we are using this type-safe conversion everywhere.  We have an open tracker to do this (http://sourceforge.net/tracker/?func=detail&atid=1033794&aid=3463497&group_id=215469).

 

I am also in the process creating a test case for checking for this issue in the win-def:registry_test and win-def:passwordpolicy_test.  I will let you know when they have been committed.  If you run into other cases of this, please add them to this tracker item (https://sourceforge.net/tracker/?group_id=617283&atid=2498336).

 

I have also added an OVAL Language tracker item to update the documentation regarding DWORDs/QWORDs to be unsigned integer values as well as consider enforcing this in the schema/schematron.  Once the public tracker is updated, the issue will be documented in tracker #33960.

 

Thanks,

Danny

 

From: Kent Landfield [mailto:[hidden email]]
Sent: Wednesday, April 04, 2012 3:09 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Proper handling and specification of DWORD/QWORD values

 

Hi Shane,

 

I agree with David's approach.  It might also be useful to forward this to the NIST SCAP Validation team so they could include it in the content test suite they distribute to the testing labs for validation testing… That might get things fixed faster. ;-)

 

Thanks.

 

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

 

From: David Solin <[hidden email]>
Reply-To: "OVAL Developer List (Closed Public Discussion)" <[hidden email]>
Date: Wed, 4 Apr 2012 12:54:57 -0500
To: "[hidden email]" <[hidden email]>
Subject: Re: [OVAL-DEVELOPER-LIST] Proper handling and specification of DWORD/QWORD values

 

Hi Shane,

I think just a documentation change should be sufficient.  Do you have an OVAL definition file handy that can be used to specifically test for this issue?  Such a test should be added to the test content file, win-def_registry_test.xml.

Regards,
--David

On 4/4/2012 11:21 AM, Shane Shaffer wrote:

Improper handling of DWORD data types in OVAL interpreters has long been an issue, though perhaps not a well known issue. Content developers have had to work around this, having to do things like seen in oval:gov.nist.usgcb.windowsseven:def:1 in the USGCB content. This issue appears to be popping up more and more frequently, so let's formally address the problem.

 

What is the issue exactly? Many interpreters are treating DWORDs as signed integers, which is incorrect. DWORDs are unsigned. The value of a DWORD may be from 0 to 4294967295, but many interpreters will return negative values once they hit 2^16. Failure to properly handle DWORD value leads to situations like in the USGCB definition above, where we have to check for the proper unsigned value (4294967295) and the improper signed value (-1).

 

Several months ago MITRE addressed this in OVALDI, at least for the case of registry values (http://sourceforge.net/tracker/index.php?func=detail&aid=3462562&group_id=215469&atid=1033794) - I don't know if the fix applied elsewhere). Though the registry is where DWORDs are most common, they do appear in other places, such as the lockoutpolicy object/state used in the referenced USGCB definition. Other OVAL scanner/interpreter developers/vendors - please make sure your tools handle DWORDs/QWORDs properly everywhere that they occur.

 

From a specification standpoint, it looks like we need to be a bit more precise to eliminate any confusion.  Looking at the OVAL schemas and Windows component specification there is no mention of these being unsigned values. All documentation of the data types currently describe DWORDs as 32 bit integers, and QWORDs as 64 bit integers. That should be amended in the next release, but I don't believe imprecise documentation is a valid excuse for interpreters to misrepresent the data.

 

Would it make sense to go farther and change the datatypes used by elements representing DWORD/QWORD values? In the case of registry state values, a datatype more precise than the current int would be preferable. Ideally there would also be Schematron validation of the value vs. the datatype, for all legal types, but I don't know how practical that is to implement. For other instances, where there is an explicit datatype on the element, more stringent types could be used. This would require the addition of something like an EntityStateUnsignedIntType, based on xml:unsignedInt, for DWORDs. For QWORDs we would want something like EntityStateUnsignedLongType, based on xml:unsignedLong, though there are currently no instances where this would be used. Or perhaps just a more generic type based on xml:nonNegativeInteger would work for these elements, if we weren't concerned with constraining the max values (which isn't done today).  Changing these types would cause a large amount of content to be trivially updated, but I think the clarity in the definitions is worth it.

 

 

Shane Shaffer

Technical Director, Security Automation
G2, Inc.

 

 

 

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

smime.p7s (9K) Download Attachment
Loading...