oval_developer@lists.cisecurity.org

A list for people interested in developing the OVAL language.

View all threads

Representing REG_SZ registry values with binary content

DS
David Solin
Thu, Feb 1, 2018 5:46 PM

Hi OVAL developers,

We’ve recently come across an interesting case where a registry value is declared to be a string type, but it has binary content (see the attached screen-shot).  I’m curious to know how other vendors deal with representing the registry_item in these circumstances.

The problem is that this particular binary data cannot be represented as a UTF-8 string within the XML.  Typically we’d consider using character escape sequences (i.e., &#XX), except in this particular case it isn’t possible, because the escape sequence “&#0” is NOT allowed to appear anywhere in an XML document!  (Neither, of course, is the raw byte sequence {0x00, 0x00}).

I’m thinking that we could represent the data using a value entity with datatype=“binary”, but given that this is a REG_SZ, it could be problematic to attempt to compare the binary content to a string value in a state.

Anyone have any thoughts?

Best regards,
—David Solin

Hi OVAL developers, We’ve recently come across an interesting case where a registry value is declared to be a string type, but it has binary content (see the attached screen-shot). I’m curious to know how other vendors deal with representing the registry_item in these circumstances. The problem is that this particular binary data cannot be represented as a UTF-8 string within the XML. Typically we’d consider using character escape sequences (i.e., &#XX), except in this particular case it isn’t possible, because the escape sequence “&#0” is NOT allowed to appear anywhere in an XML document! (Neither, of course, is the raw byte sequence {0x00, 0x00}). I’m thinking that we could represent the data using a value entity with datatype=“binary”, but given that this is a REG_SZ, it could be problematic to attempt to compare the binary content to a string value in a state. Anyone have any thoughts? Best regards, —David Solin
VJ
Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US)
Fri, Feb 16, 2018 5:47 PM

I'm wondering if just reporting this as error makes the most sense?  Really bizarre that someone would choose to put binary data in a string field.  I'm not sure we currently do much of anything with the data, but something I'm tracking for an update.

Jack Vander Pol
SPAWAR Systems Center Atlantic
jack.vanderpol@navy.mil
843-218-5851


From: OVAL_Developer [oval_developer-bounces@lists.cisecurity.org] on behalf of David Solin [solin@jovalcm.com]
Sent: Thursday, February 01, 2018 12:46 PM
To: OVAL Developer List
Subject: [Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ registry values with binary content

Hi OVAL developers,

We’ve recently come across an interesting case where a registry value is declared to be a string type, but it has binary content (see the attached screen-shot).  I’m curious to know how other vendors deal with representing the registry_item in these circumstances.

The problem is that this particular binary data cannot be represented as a UTF-8 string within the XML.  Typically we’d consider using character escape sequences (i.e., &#XX), except in this particular case it isn’t possible, because the escape sequence “&#0” is NOT allowed to appear anywhere in an XML document!  (Neither, of course, is the raw byte sequence {0x00, 0x00}).

I’m thinking that we could represent the data using a value entity with datatype=“binary”, but given that this is a REG_SZ, it could be problematic to attempt to compare the binary content to a string value in a state.

Anyone have any thoughts?

Best regards,
—David Solin

[cid:0C1AF053-FED0-4F2B-A582-3CC6D4FCC98A@lan]

I'm wondering if just reporting this as error makes the most sense? Really bizarre that someone would choose to put binary data in a string field. I'm not sure we currently do much of anything with the data, but something I'm tracking for an update. Jack Vander Pol SPAWAR Systems Center Atlantic jack.vanderpol@navy.mil 843-218-5851 ________________________________ From: OVAL_Developer [oval_developer-bounces@lists.cisecurity.org] on behalf of David Solin [solin@jovalcm.com] Sent: Thursday, February 01, 2018 12:46 PM To: OVAL Developer List Subject: [Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ registry values with binary content Hi OVAL developers, We’ve recently come across an interesting case where a registry value is declared to be a string type, but it has binary content (see the attached screen-shot). I’m curious to know how other vendors deal with representing the registry_item in these circumstances. The problem is that this particular binary data cannot be represented as a UTF-8 string within the XML. Typically we’d consider using character escape sequences (i.e., &#XX), except in this particular case it isn’t possible, because the escape sequence “&#0” is NOT allowed to appear anywhere in an XML document! (Neither, of course, is the raw byte sequence {0x00, 0x00}). I’m thinking that we could represent the data using a value entity with datatype=“binary”, but given that this is a REG_SZ, it could be problematic to attempt to compare the binary content to a string value in a state. Anyone have any thoughts? Best regards, —David Solin [cid:0C1AF053-FED0-4F2B-A582-3CC6D4FCC98A@lan]
DP
Dragos Prisaca
Fri, Feb 16, 2018 5:52 PM

I agree with Jack, I think an error makes more sense in this case where
binary data is stored in a reg_sz.

Thanks,

_Dragos.

From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org] *On
Behalf Of *Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US)
Sent: Friday, February 16, 2018 12:47 PM
To: David Solin solin@jovalcm.com; OVAL Developer List <
oval_developer@lists.cisecurity.org>
Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Representing REG_SZ
registry values with binary content

I'm wondering if just reporting this as error makes the most sense?  Really
bizarre that someone would choose to put binary data in a string field.
I'm not sure we currently do much of anything with the data, but something
I'm tracking for an update.

Jack Vander Pol

SPAWAR Systems Center Atlantic

jack.vanderpol@navy.mil

843-218-5851

From: OVAL_Developer [oval_developer-bounces@lists.cisecurity.org] on
behalf of David Solin [solin@jovalcm.com]
Sent: Thursday, February 01, 2018 12:46 PM
To: OVAL Developer List
Subject: [Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ registry
values with binary content

Hi OVAL developers,

We’ve recently come across an interesting case where a registry value is
declared to be a string type, but it has binary content (see the attached
screen-shot).  I’m curious to know how other vendors deal with representing
the registry_item in these circumstances.

The problem is that this particular binary data cannot be represented as a
UTF-8 string within the XML.  Typically we’d consider using character
escape sequences (i.e., &#XX), except in this particular case it isn’t
possible, because the escape sequence “&#0” is NOT allowed to appear
anywhere in an XML document!  (Neither, of course, is the raw byte sequence
{0x00, 0x00}).

I’m thinking that we could represent the data using a value entity with
datatype=“binary”, but given that this is a REG_SZ, it could be problematic
to attempt to compare the binary content to a string value in a state.

Anyone have any thoughts?

Best regards,

—David Solin

I agree with Jack, I think an error makes more sense in this case where binary data is stored in a reg_sz. Thanks, _Dragos. *From:* OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org] *On Behalf Of *Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) *Sent:* Friday, February 16, 2018 12:47 PM *To:* David Solin <solin@jovalcm.com>; OVAL Developer List < oval_developer@lists.cisecurity.org> *Subject:* Re: [OVAL DEVELOPER] [Non-DoD Source] Representing REG_SZ registry values with binary content I'm wondering if just reporting this as error makes the most sense? Really bizarre that someone would choose to put binary data in a string field. I'm not sure we currently do much of anything with the data, but something I'm tracking for an update. Jack Vander Pol SPAWAR Systems Center Atlantic jack.vanderpol@navy.mil 843-218-5851 ------------------------------ *From:* OVAL_Developer [oval_developer-bounces@lists.cisecurity.org] on behalf of David Solin [solin@jovalcm.com] *Sent:* Thursday, February 01, 2018 12:46 PM *To:* OVAL Developer List *Subject:* [Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ registry values with binary content Hi OVAL developers, We’ve recently come across an interesting case where a registry value is declared to be a string type, but it has binary content (see the attached screen-shot). I’m curious to know how other vendors deal with representing the registry_item in these circumstances. The problem is that this particular binary data cannot be represented as a UTF-8 string within the XML. Typically we’d consider using character escape sequences (i.e., &#XX), except in this particular case it isn’t possible, because the escape sequence “&#0” is NOT allowed to appear anywhere in an XML document! (Neither, of course, is the raw byte sequence {0x00, 0x00}). I’m thinking that we could represent the data using a value entity with datatype=“binary”, but given that this is a REG_SZ, it could be problematic to attempt to compare the binary content to a string value in a state. Anyone have any thoughts? Best regards, —David Solin
G
Gunnar
Fri, Feb 16, 2018 6:05 PM

I have to disagree.

The data exists, as described, and being able to process it is necessary
for purposes of security evaluation.

Or, to restate that, creating and error condition is of no help to the
user -- they cannot be expected to change the data to match OVAL
expectations.  Reporting the condition as an error doesn't help the user
with their security evaluation.

So it's back to the question David posted -- how to represent this case
so that further processing can happen?  It looks like a schema change
will be necessary to allow for encoding of binary data. Something that
would be needed anyway.

On 02/16/2018 09:52 AM, Dragos Prisaca wrote:

I agree with Jack, I think an error makes more sense in this case
where binary data is stored in a reg_sz.

Thanks,

_Dragos.

From: OVAL_Developer
[mailto:oval_developer-bounces@lists.cisecurity.org
mailto:oval_developer-bounces@lists.cisecurity.org] *On Behalf Of
*Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US)
Sent: Friday, February 16, 2018 12:47 PM
To: David Solin <solin@jovalcm.com mailto:solin@jovalcm.com>; OVAL
Developer List <oval_developer@lists.cisecurity.org
mailto:oval_developer@lists.cisecurity.org>
Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Representing REG_SZ
registry values with binary content

I'm wondering if just reporting this as error makes the most sense? 
Really bizarre that someone would choose to put binary data in a
string field.  I'm not sure we currently do much of anything with the
data, but something I'm tracking for an update.

Jack Vander Pol

SPAWAR Systems Center Atlantic

jack.vanderpol@navy.mil mailto:jack.vanderpol@navy.mil

843-218-5851


*From:*OVAL_Developer [oval_developer-bounces@lists.cisecurity.org
mailto:oval_developer-bounces@lists.cisecurity.org] on behalf of
David Solin [solin@jovalcm.com mailto:solin@jovalcm.com]
Sent: Thursday, February 01, 2018 12:46 PM
To: OVAL Developer List
Subject: [Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ
registry values with binary content

Hi OVAL developers,

We’ve recently come across an interesting case where a registry value
is declared to be a string type, but it has binary content (see the
attached screen-shot).  I’m curious to know how other vendors deal
with representing the registry_item in these circumstances.

The problem is that this particular binary data cannot be represented
as a UTF-8 string within the XML.  Typically we’d consider using
character escape sequences (i.e., &#XX), except in this particular
case it isn’t possible, because the escape sequence “&#0” is NOT
allowed to appear anywhere in an XML document!  (Neither, of course,
is the raw byte sequence {0x00, 0x00}).

I’m thinking that we could represent the data using a value entity
with datatype=“binary”, but given that this is a REG_SZ, it could be
problematic to attempt to compare the binary content to a string value
in a state.

Anyone have any thoughts?

Best regards,

—David Solin


OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org

I have to disagree. The data exists, as described, and being able to process it is necessary for purposes of security evaluation. Or, to restate that, creating and error condition is of no help to the user -- they cannot be expected to change the data to match OVAL expectations.  Reporting the condition as an error doesn't help the user with their security evaluation. So it's back to the question David posted -- how to represent this case so that further processing can happen?  It looks like a schema change will be necessary to allow for encoding of binary data. Something that would be needed anyway. On 02/16/2018 09:52 AM, Dragos Prisaca wrote: > > I agree with Jack, I think an error makes more sense in this case > where binary data is stored in a reg_sz. > > Thanks, > > _Dragos. > > *From:* OVAL_Developer > [mailto:oval_developer-bounces@lists.cisecurity.org > <mailto:oval_developer-bounces@lists.cisecurity.org>] *On Behalf Of > *Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) > *Sent:* Friday, February 16, 2018 12:47 PM > *To:* David Solin <solin@jovalcm.com <mailto:solin@jovalcm.com>>; OVAL > Developer List <oval_developer@lists.cisecurity.org > <mailto:oval_developer@lists.cisecurity.org>> > *Subject:* Re: [OVAL DEVELOPER] [Non-DoD Source] Representing REG_SZ > registry values with binary content > > I'm wondering if just reporting this as error makes the most sense?  > Really bizarre that someone would choose to put binary data in a > string field.  I'm not sure we currently do much of anything with the > data, but something I'm tracking for an update. > > Jack Vander Pol > > SPAWAR Systems Center Atlantic > > jack.vanderpol@navy.mil <mailto:jack.vanderpol@navy.mil> > > 843-218-5851 > > ------------------------------------------------------------------------ > > *From:*OVAL_Developer [oval_developer-bounces@lists.cisecurity.org > <mailto:oval_developer-bounces@lists.cisecurity.org>] on behalf of > David Solin [solin@jovalcm.com <mailto:solin@jovalcm.com>] > *Sent:* Thursday, February 01, 2018 12:46 PM > *To:* OVAL Developer List > *Subject:* [Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ > registry values with binary content > > Hi OVAL developers, > > We’ve recently come across an interesting case where a registry value > is declared to be a string type, but it has binary content (see the > attached screen-shot).  I’m curious to know how other vendors deal > with representing the registry_item in these circumstances. > > The problem is that this particular binary data cannot be represented > as a UTF-8 string within the XML.  Typically we’d consider using > character escape sequences (i.e., &#XX), except in this particular > case it isn’t possible, because the escape sequence “&#0” is NOT > allowed to appear anywhere in an XML document!  (Neither, of course, > is the raw byte sequence {0x00, 0x00}). > > I’m thinking that we could represent the data using a value entity > with datatype=“binary”, but given that this is a REG_SZ, it could be > problematic to attempt to compare the binary content to a string value > in a state. > > Anyone have any thoughts? > > Best regards, > > —David Solin > > > > _______________________________________________ > OVAL_Developer mailing list > OVAL_Developer@lists.cisecurity.org > http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
DS
David Solin
Fri, Feb 16, 2018 6:59 PM

Well, it wouldn’t require any kind of a schema change, it would only require a documentation note.  The schema already has a binary datatype, and notably, it is used for representing REG_BINARY data.

I agree that recording an error does little for the content author, however, I believe this might be an error condition nevertheless.

—David Solin

On Feb 16, 2018, at 12:05 PM, Gunnar gunnar.engelbach@threatguard.com wrote:

I have to disagree.

The data exists, as described, and being able to process it is necessary for purposes of security evaluation.

Or, to restate that, creating and error condition is of no help to the user -- they cannot be expected to change the data to match OVAL expectations.  Reporting the condition as an error doesn't help the user with their security evaluation.

So it's back to the question David posted -- how to represent this case so that further processing can happen?  It looks like a schema change will be necessary to allow for encoding of binary data.  Something that would be needed anyway.

On 02/16/2018 09:52 AM, Dragos Prisaca wrote:

I agree with Jack, I think an error makes more sense in this case where binary data is stored in a reg_sz.

Thanks,
_Dragos.

From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org mailto:oval_developer-bounces@lists.cisecurity.org] On Behalf Of Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US)
Sent: Friday, February 16, 2018 12:47 PM
To: David Solin <solin@jovalcm.com mailto:solin@jovalcm.com>; OVAL Developer List <oval_developer@lists.cisecurity.org mailto:oval_developer@lists.cisecurity.org>
Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Representing REG_SZ registry values with binary content

I'm wondering if just reporting this as error makes the most sense?  Really bizarre that someone would choose to put binary data in a string field.  I'm not sure we currently do much of anything with the data, but something I'm tracking for an update.

Jack Vander Pol
SPAWAR Systems Center Atlantic
jack.vanderpol@navy.mil mailto:jack.vanderpol@navy.mil
843-218-5851
From: OVAL_Developer [oval_developer-bounces@lists.cisecurity.org mailto:oval_developer-bounces@lists.cisecurity.org] on behalf of David Solin [solin@jovalcm.com mailto:solin@jovalcm.com]
Sent: Thursday, February 01, 2018 12:46 PM
To: OVAL Developer List
Subject: [Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ registry values with binary content

Hi OVAL developers,

We’ve recently come across an interesting case where a registry value is declared to be a string type, but it has binary content (see the attached screen-shot).  I’m curious to know how other vendors deal with representing the registry_item in these circumstances.

The problem is that this particular binary data cannot be represented as a UTF-8 string within the XML.  Typically we’d consider using character escape sequences (i.e., &#XX), except in this particular case it isn’t possible, because the escape sequence “&#0” is NOT allowed to appear anywhere in an XML document!  (Neither, of course, is the raw byte sequence {0x00, 0x00}).

I’m thinking that we could represent the data using a value entity with datatype=“binary”, but given that this is a REG_SZ, it could be problematic to attempt to compare the binary content to a string value in a state.

Anyone have any thoughts?

Best regards,
—David Solin

<image001.png>


OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.org mailto:OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org

Well, it wouldn’t require any kind of a schema change, it would only require a documentation note. The schema already has a binary datatype, and notably, it is used for representing REG_BINARY data. I agree that recording an error does little for the content author, however, I believe this might be an error condition nevertheless. —David Solin > On Feb 16, 2018, at 12:05 PM, Gunnar <gunnar.engelbach@threatguard.com> wrote: > > > I have to disagree. > > The data exists, as described, and being able to process it is necessary for purposes of security evaluation. > > Or, to restate that, creating and error condition is of no help to the user -- they cannot be expected to change the data to match OVAL expectations. Reporting the condition as an error doesn't help the user with their security evaluation. > > So it's back to the question David posted -- how to represent this case so that further processing can happen? It looks like a schema change will be necessary to allow for encoding of binary data. Something that would be needed anyway. > > > > On 02/16/2018 09:52 AM, Dragos Prisaca wrote: >> I agree with Jack, I think an error makes more sense in this case where binary data is stored in a reg_sz. >> >> Thanks, >> _Dragos. >> >> From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org <mailto:oval_developer-bounces@lists.cisecurity.org>] On Behalf Of Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) >> Sent: Friday, February 16, 2018 12:47 PM >> To: David Solin <solin@jovalcm.com <mailto:solin@jovalcm.com>>; OVAL Developer List <oval_developer@lists.cisecurity.org <mailto:oval_developer@lists.cisecurity.org>> >> Subject: Re: [OVAL DEVELOPER] [Non-DoD Source] Representing REG_SZ registry values with binary content >> >> I'm wondering if just reporting this as error makes the most sense? Really bizarre that someone would choose to put binary data in a string field. I'm not sure we currently do much of anything with the data, but something I'm tracking for an update. >> >> Jack Vander Pol >> SPAWAR Systems Center Atlantic >> jack.vanderpol@navy.mil <mailto:jack.vanderpol@navy.mil> >> 843-218-5851 >> From: OVAL_Developer [oval_developer-bounces@lists.cisecurity.org <mailto:oval_developer-bounces@lists.cisecurity.org>] on behalf of David Solin [solin@jovalcm.com <mailto:solin@jovalcm.com>] >> Sent: Thursday, February 01, 2018 12:46 PM >> To: OVAL Developer List >> Subject: [Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ registry values with binary content >> >> Hi OVAL developers, >> >> We’ve recently come across an interesting case where a registry value is declared to be a string type, but it has binary content (see the attached screen-shot). I’m curious to know how other vendors deal with representing the registry_item in these circumstances. >> >> The problem is that this particular binary data cannot be represented as a UTF-8 string within the XML. Typically we’d consider using character escape sequences (i.e., &#XX), except in this particular case it isn’t possible, because the escape sequence “&#0” is NOT allowed to appear anywhere in an XML document! (Neither, of course, is the raw byte sequence {0x00, 0x00}). >> >> I’m thinking that we could represent the data using a value entity with datatype=“binary”, but given that this is a REG_SZ, it could be problematic to attempt to compare the binary content to a string value in a state. >> >> Anyone have any thoughts? >> >> Best regards, >> —David Solin >> >> <image001.png> >> >> >> _______________________________________________ >> OVAL_Developer mailing list >> OVAL_Developer@lists.cisecurity.org <mailto:OVAL_Developer@lists.cisecurity.org> >> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org <http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org> > >
G
gunnar
Sat, Feb 17, 2018 12:53 AM

I'm really not concerned with the content author, except for indirectly.

My concern is the poor schlub whose computers have a peculiarity such as
this and just needs to know if that state represents a security risk or
not.  If a tool tells him it's an error condition, then that tool is of
no use.  Given a choice between a tool that says it can't evaluate
something and one that can, guess which one wins.

To state it more broadly, if OVAL can't facilitate operations in the
world as it exists then OVAL is of no use.

Now, it may fall upon a content author to be able to construct a test
that accounts for this situation, hence my comment about only caring
about the content author indirectly.

--gun

On 2/16/2018 10:59 AM, David Solin wrote:

Well, it wouldn’t require any kind of a schema change, it would only
require a documentation note.  The schema already has a binary
datatype, and notably, it is used for representing REG_BINARY data.

I agree that recording an error does little for the content author,
however, I believe this might be an error condition nevertheless.

—David Solin

On Feb 16, 2018, at 12:05 PM, Gunnar
<gunnar.engelbach@threatguard.com
mailto:gunnar.engelbach@threatguard.com> wrote:

I have to disagree.

The data exists, as described, and being able to process it is
necessary for purposes of security evaluation.

Or, to restate that, creating and error condition is of no help to
the user -- they cannot be expected to change the data to match OVAL
expectations.  Reporting the condition as an error doesn't help the
user with their security evaluation.

So it's back to the question David posted -- how to represent this
case so that further processing can happen?  It looks like a schema
change will be necessary to allow for encoding of binary data. 
Something that would be needed anyway.

On 02/16/2018 09:52 AM, Dragos Prisaca wrote:

I agree with Jack, I think an error makes more sense in this case
where binary data is stored in a reg_sz.

Thanks,
_Dragos.

*From:*OVAL_Developer
[mailto:oval_developer-bounces@lists.cisecurity.org
mailto:oval_developer-bounces@lists.cisecurity.org]On Behalf
Of
Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US)
*Sent:*Friday, February 16, 2018 12:47 PM
*To:*David Solin <solin@jovalcm.com mailto:solin@jovalcm.com>;
OVAL Developer List <oval_developer@lists.cisecurity.org
mailto:oval_developer@lists.cisecurity.org>
*Subject:*Re: [OVAL DEVELOPER] [Non-DoD Source] Representing REG_SZ
registry values with binary content

I'm wondering if just reporting this as error makes the most sense? 
Really bizarre that someone would choose to put binary data in a
string field.  I'm not sure we currently do much of anything with
the data, but something I'm tracking for an update.

Jack Vander Pol
SPAWAR Systems Center Atlantic
jack.vanderpol@navy.mil mailto:jack.vanderpol@navy.mil
843-218-5851

*From:*OVAL_Developer [oval_developer-bounces@lists.cisecurity.org
mailto:oval_developer-bounces@lists.cisecurity.org] on behalf of
David Solin [solin@jovalcm.com mailto:solin@jovalcm.com]
*Sent:*Thursday, February 01, 2018 12:46 PM
*To:*OVAL Developer List
Subject:[Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ
registry values with binary content

Hi OVAL developers,

We’ve recently come across an interesting case where a registry
value is declared to be a string type, but it has binary content
(see the attached screen-shot).  I’m curious to know how other
vendors deal with representing the registry_item in these circumstances.

The problem is that this particular binary data cannot be
represented as a UTF-8 string within the XML.  Typically we’d
consider using character escape sequences (i.e., &#XX), except in
this particular case it isn’t possible, because the escape sequence
“&#0” is NOT allowed to appear anywhere in an XML document!
 (Neither, of course, is the raw byte sequence {0x00, 0x00}).

I’m thinking that we could represent the data using a value entity
with datatype=“binary”, but given that this is a REG_SZ, it could be
problematic to attempt to compare the binary content to a string
value in a state.

Anyone have any thoughts?

Best regards,
—David Solin

<image001.png>


OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org

I'm really not concerned with the content author, except for indirectly. My concern is the poor schlub whose computers have a peculiarity such as this and just needs to know if that state represents a security risk or not.  If a tool tells him it's an error condition, then that tool is of no use.  Given a choice between a tool that says it can't evaluate something and one that can, guess which one wins. To state it more broadly, if OVAL can't facilitate operations in the world as it exists then OVAL is of no use. Now, it may fall upon a content author to be able to construct a test that accounts for this situation, hence my comment about only caring about the content author indirectly. --gun On 2/16/2018 10:59 AM, David Solin wrote: > Well, it wouldn’t require any kind of a schema change, it would only > require a documentation note.  The schema already has a binary > datatype, and notably, it is used for representing REG_BINARY data. > > I agree that recording an error does little for the content author, > however, I believe this might be an error condition nevertheless. > > —David Solin > >> On Feb 16, 2018, at 12:05 PM, Gunnar >> <gunnar.engelbach@threatguard.com >> <mailto:gunnar.engelbach@threatguard.com>> wrote: >> >> >> I have to disagree. >> >> The data exists, as described, and being able to process it is >> necessary for purposes of security evaluation. >> >> Or, to restate that, creating and error condition is of no help to >> the user -- they cannot be expected to change the data to match OVAL >> expectations.  Reporting the condition as an error doesn't help the >> user with their security evaluation. >> >> So it's back to the question David posted -- how to represent this >> case so that further processing can happen?  It looks like a schema >> change will be necessary to allow for encoding of binary data.  >> Something that would be needed anyway. >> >> >> >> On 02/16/2018 09:52 AM, Dragos Prisaca wrote: >>> I agree with Jack, I think an error makes more sense in this case >>> where binary data is stored in a reg_sz. >>> >>> Thanks, >>> _Dragos. >>> >>> *From:*OVAL_Developer >>> [mailto:oval_developer-bounces@lists.cisecurity.org >>> <mailto:oval_developer-bounces@lists.cisecurity.org>]*On Behalf >>> Of*Vanderpol, Jack R CIV USN SPAWARSYSCEN LANT SC (US) >>> *Sent:*Friday, February 16, 2018 12:47 PM >>> *To:*David Solin <solin@jovalcm.com <mailto:solin@jovalcm.com>>; >>> OVAL Developer List <oval_developer@lists.cisecurity.org >>> <mailto:oval_developer@lists.cisecurity.org>> >>> *Subject:*Re: [OVAL DEVELOPER] [Non-DoD Source] Representing REG_SZ >>> registry values with binary content >>> >>> I'm wondering if just reporting this as error makes the most sense?  >>> Really bizarre that someone would choose to put binary data in a >>> string field.  I'm not sure we currently do much of anything with >>> the data, but something I'm tracking for an update. >>> >>> Jack Vander Pol >>> SPAWAR Systems Center Atlantic >>> jack.vanderpol@navy.mil <mailto:jack.vanderpol@navy.mil> >>> 843-218-5851 >>> ------------------------------------------------------------------------ >>> >>> *From:*OVAL_Developer [oval_developer-bounces@lists.cisecurity.org >>> <mailto:oval_developer-bounces@lists.cisecurity.org>] on behalf of >>> David Solin [solin@jovalcm.com <mailto:solin@jovalcm.com>] >>> *Sent:*Thursday, February 01, 2018 12:46 PM >>> *To:*OVAL Developer List >>> *Subject:*[Non-DoD Source] [OVAL DEVELOPER] Representing REG_SZ >>> registry values with binary content >>> >>> Hi OVAL developers, >>> >>> We’ve recently come across an interesting case where a registry >>> value is declared to be a string type, but it has binary content >>> (see the attached screen-shot).  I’m curious to know how other >>> vendors deal with representing the registry_item in these circumstances. >>> >>> The problem is that this particular binary data cannot be >>> represented as a UTF-8 string within the XML.  Typically we’d >>> consider using character escape sequences (i.e., &#XX), except in >>> this particular case it isn’t possible, because the escape sequence >>> “&#0” is NOT allowed to appear anywhere in an XML document! >>>  (Neither, of course, is the raw byte sequence {0x00, 0x00}). >>> >>> I’m thinking that we could represent the data using a value entity >>> with datatype=“binary”, but given that this is a REG_SZ, it could be >>> problematic to attempt to compare the binary content to a string >>> value in a state. >>> >>> Anyone have any thoughts? >>> >>> Best regards, >>> —David Solin >>> >>> <image001.png> >>> >>> >>> _______________________________________________ >>> OVAL_Developer mailing list >>> OVAL_Developer@lists.cisecurity.org >>> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org >> >> >