Hello OVAL devs, I've been looking at some of Red Hat's published vulnerability definitions and came across this rpmverifyfile_object. I wanted to get people's opinions on it because I don't think it's valid... <red-def:rpmverifyfile_object id="oval:com.redhat.rhba:obj:20070304015" version="638"> <red-def:behaviors noconfigfiles="true" noghostfiles="true" nogroup="true" nolinkto="true" nomd5="true" nomode="true" nomtime="true" nordev="true" nosize="true" nouser="true"/> <red-def:name operation="pattern match"/> <red-def:epoch operation="pattern match"/> <red-def:version operation="pattern match"/> <red-def:release operation="pattern match"/> <red-def:arch operation="pattern match"/> <red-def:filepath>/etc/redhat-release</red-def:filepath> </red-def:rpmverifyfile_object> Most of the child elements (name, epoch, version, release, and arch) are all pattern matching against nothing. Wouldn't this always yield "does not exist"? Is this object intended to be pattern matching all those elements using ".*"? Thanks in advance for any opinions! Cheers, -Bill M. Bill Munyan Solutions/Software Architect; Security Best Practices 31 Tech Valley Drive East Greenbush, NY 12061 william.munyan@cisecurity.org<mailto:william.munyan@cisecurity.org> (518) 516-6128 (w) (518) 281-1233 (c) [CIS_WEB_Logo_Type_RGB_Flat]<https://www.cisecurity.org/> [CIS Email Icons 01_23-02] <https://www.facebook.com/CenterforIntSec> [CIS Email Icons 01_23-03] <https://twitter.com/CISecurity> [CIS Email Icons 01_23-04] <https://www.youtube.com/user/TheCISecurity> [CIS Email Icons 01_23-05] <https://www.linkedin.com/company/the-center-for-internet-security> This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

Isn't pattern-matching an empty expression equivalent to a wildcard? > On Sep 28, 2020, at 2:59 PM, William Munyan via OVAL_Developer <oval_developer@lists.cisecurity.org> wrote: > > Hello OVAL devs, > I’ve been looking at some of Red Hat’s published vulnerability definitions and came across this rpmverifyfile_object. I wanted to get people’s opinions on it because I don’t think it’s valid… > > <red-def:rpmverifyfile_object id="oval:com.redhat.rhba:obj:20070304015" version="638"> > <red-def:behaviors noconfigfiles="true" noghostfiles="true" nogroup="true" nolinkto="true" nomd5="true" nomode="true" nomtime="true" nordev="true" nosize="true" nouser="true"/> > <red-def:name operation="pattern match"/> > <red-def:epoch operation="pattern match"/> > <red-def:version operation="pattern match"/> > <red-def:release operation="pattern match"/> > <red-def:arch operation="pattern match"/> > <red-def:filepath>/etc/redhat-release</red-def:filepath> > </red-def:rpmverifyfile_object> > > Most of the child elements (name, epoch, version, release, and arch) are all pattern matching against nothing. Wouldn’t this always yield “does not exist”? Is this object intended to be pattern matching all those elements using “.*”? > > Thanks in advance for any opinions! > > Cheers, > -Bill M. > > Bill Munyan > Solutions/Software Architect; Security Best Practices > 31 Tech Valley Drive > East Greenbush, NY 12061 > > william.munyan@cisecurity.org <mailto:william.munyan@cisecurity.org> > (518) 516-6128 (w) > (518) 281-1233 (c) > <image001.png> <https://www.cisecurity.org/> > <image002.png> <https://protect-us.mimecast.com/s/aHtwCqxpOwH8Qx0KSZNdK-?domain=facebook.com> <image003.png> <https://protect-us.mimecast.com/s/bGw6CrkqPyt8qzVPSzJlFz?domain=twitter.com> <image004.png> <https://protect-us.mimecast.com/s/NUbHCv2xWKt79PNpcz_MPb?domain=youtube.com> <image005.png> <https://protect-us.mimecast.com/s/r0yoCwpyXMSGj48JFKd5lK?domain=linkedin.com> > > > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. _______________________________________________ > 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>

So, we’re supposed to consider an empty expression the same as .*? From: David Solin <solin@jovalcm.com> Sent: Monday, September 28, 2020 4:37 PM To: William Munyan <William.Munyan@cisecurity.org> Cc: oval_developer@lists.cisecurity.org Subject: Re: [OVAL DEVELOPER] Odd Red Hat Content Isn't pattern-matching an empty expression equivalent to a wildcard? On Sep 28, 2020, at 2:59 PM, William Munyan via OVAL_Developer <oval_developer@lists.cisecurity.org<mailto:oval_developer@lists.cisecurity.org>> wrote: Hello OVAL devs, I’ve been looking at some of Red Hat’s published vulnerability definitions and came across this rpmverifyfile_object. I wanted to get people’s opinions on it because I don’t think it’s valid… <red-def:rpmverifyfile_object id="oval:com.redhat.rhba:obj:20070304015" version="638"> <red-def:behaviors noconfigfiles="true" noghostfiles="true" nogroup="true" nolinkto="true" nomd5="true" nomode="true" nomtime="true" nordev="true" nosize="true" nouser="true"/> <red-def:name operation="pattern match"/> <red-def:epoch operation="pattern match"/> <red-def:version operation="pattern match"/> <red-def:release operation="pattern match"/> <red-def:arch operation="pattern match"/> <red-def:filepath>/etc/redhat-release</red-def:filepath> </red-def:rpmverifyfile_object> Most of the child elements (name, epoch, version, release, and arch) are all pattern matching against nothing. Wouldn’t this always yield “does not exist”? Is this object intended to be pattern matching all those elements using “.*”? Thanks in advance for any opinions! Cheers, -Bill M. Bill Munyan Solutions/Software Architect; Security Best Practices 31 Tech Valley Drive East Greenbush, NY 12061 william.munyan@cisecurity.org<mailto:william.munyan@cisecurity.org> (518) 516-6128 (w) (518) 281-1233 (c) <image001.png><https://www.cisecurity.org/> <image002.png><https://www.facebook.com/CenterforIntSec> <image003.png><https://twitter.com/CISecurity> <image004.png><https://www.youtube.com/user/TheCISecurity> <image005.png><https://www.linkedin.com/company/the-center-for-internet-security> This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. _______________________________________________ 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 ..... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

Well, in Java anyway, java.util.regex.Pattern.compile("").matcher("anything").find() will always return true. So if you’re comparing the pattern to a string using find(), it will function like a wildcard. (The behavior of Matcher.groupCount and Matcher.group is a different story). This may just be an implementation detail of Java — but I am guessing the behavior of whatever C library OpenSCAP is using for regular expression matching must behave similarly, judging from this snippet. And since those are all EntityObjectStringType entities, not setting a value is equivalent to setting the value to an empty string. There’s nothing in the OVAL specification or schema docs that say this, however. So I can certainly appreciate the perspective that this content maybe isn’t valid. It does schema-validate, though. Best regards, —David > On Sep 28, 2020, at 3:45 PM, William Munyan via OVAL_Developer <oval_developer@lists.cisecurity.org> wrote: > > So, we’re supposed to consider an empty expression the same as .*? > > From: David Solin <solin@jovalcm.com <mailto:solin@jovalcm.com>> > Sent: Monday, September 28, 2020 4:37 PM > To: William Munyan <William.Munyan@cisecurity.org <mailto:William.Munyan@cisecurity.org>> > Cc: oval_developer@lists.cisecurity.org <mailto:oval_developer@lists.cisecurity.org> > Subject: Re: [OVAL DEVELOPER] Odd Red Hat Content > > > > > Isn't pattern-matching an empty expression equivalent to a wildcard? > > > On Sep 28, 2020, at 2:59 PM, William Munyan via OVAL_Developer <oval_developer@lists.cisecurity.org <mailto:oval_developer@lists.cisecurity.org>> wrote: > > Hello OVAL devs, > I’ve been looking at some of Red Hat’s published vulnerability definitions and came across this rpmverifyfile_object. I wanted to get people’s opinions on it because I don’t think it’s valid… > > <red-def:rpmverifyfile_object id="oval:com.redhat.rhba:obj:20070304015" version="638"> > <red-def:behaviors noconfigfiles="true" noghostfiles="true" nogroup="true" nolinkto="true" nomd5="true" nomode="true" nomtime="true" nordev="true" nosize="true" nouser="true"/> > <red-def:name operation="pattern match"/> > <red-def:epoch operation="pattern match"/> > <red-def:version operation="pattern match"/> > <red-def:release operation="pattern match"/> > <red-def:arch operation="pattern match"/> > <red-def:filepath>/etc/redhat-release</red-def:filepath> > </red-def:rpmverifyfile_object> > > Most of the child elements (name, epoch, version, release, and arch) are all pattern matching against nothing. Wouldn’t this always yield “does not exist”? Is this object intended to be pattern matching all those elements using “.*”? > > Thanks in advance for any opinions! > > Cheers, > -Bill M. > > Bill Munyan > Solutions/Software Architect; Security Best Practices > 31 Tech Valley Drive > East Greenbush, NY 12061 > > william.munyan@cisecurity.org <mailto:william.munyan@cisecurity.org> > (518) 516-6128 (w) > (518) 281-1233 (c) > <image001.png> <https://www.cisecurity.org/> > <image002.png> <https://protect-us.mimecast.com/s/-SMvC5ywmJHZJ70DizkOkH?domain=facebook.com> <image003.png> <https://protect-us.mimecast.com/s/7DnfC68xnLSrNvoBh66Xcy?domain=twitter.com> <image004.png> <https://protect-us.mimecast.com/s/uByWC73yoNCAgKmJsBc_fn?domain=youtube.com> <image005.png> <https://protect-us.mimecast.com/s/6mxtC82zpPt6G0jKhMqOIj?domain=linkedin.com> > > > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. _______________________________________________ > 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> > > > ..... > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. _______________________________________________ > 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>