oval_developer@lists.cisecurity.org
A list for people interested in developing the OVAL language.
View all threadsAutomated Generation of OVAL Vulnerability Definitions for Microsoft Windows
Hi David,
Yes, that does make sense. Thanks for the clarification.
Thanks,
Alexander
From: David Ries [mailto:ries@jovalcm.com]
Sent: Friday, January 06, 2017 10:47 PM
To: Chua, Alexander
Cc: Jerome Athias; oval_developer@lists.cisecurity.orgmailto:oval_developer@lists.cisecurity.org
Subject: Re: [OVAL DEVELOPER] Automated Generation of OVAL Vulnerability Definitions for Microsoft Windows
Hi Alexander,
The way I understand the proposal (and I’m not 100% sure here) is that if foo.dll v1 does not exists, then the result of the OVAL definition will be true (vulnerable). Because foo.dll v1 is the patch for CVE-FOO. If you don’t have it on March 1st, you are vulnerable.
The key difference between this approach and most current content that I’ve seen, is that the content is not actually checking to see if you have the vulnerable component or configuration. It’s checking to see if you have the 1st fix shipped by MS.
However, in my example starting May 1st, the fact that you’re missing foo.dll doesn’t necessarily mean you’re vulnerable. The script would need to understand that KB 3 supersedes KB 1 and therefore also resolves CVE-FOO. Then the OVAL would need to be revised to check for foo.dll v1+ OR foo2.dll v1+.
The potential issue is that MS often ships rollups and other subsequent patches that supersede the initial fix and may add/remove/update all sorts of files, registry settings and etc.
Does that make sense or am I missing your point?
-David
On Jan 6, 2017, at 2:05 AM, Chua, Alexander <AChua@dtcc.commailto:AChua@dtcc.com> wrote:
Hi David/Jerome,
Just my two cents on the last part. If I understand it correctly, I think it wouldn’t have a false-positive result, since the OVAL definition created for the CVE-FOO will be looking for the foo.dll v1. And if the KB 3 remove it, then the OVAL definition for CVE-FOO would not be able to find it and will return a result of false indicating that the machine is not vulnerable for CVE-FOO.
Thanks,
Alexander
From: OVAL_Developer [mailto:oval_developer-bounces@lists.cisecurity.org] On Behalf Of Jerome Athias
Sent: Friday, January 06, 2017 3:13 PM
To: David Ries
Cc: oval_developer@lists.cisecurity.orgmailto:oval_developer@lists.cisecurity.org
Subject: Re: [OVAL DEVELOPER] Automated Generation of OVAL Vulnerability Definitions for Microsoft Windows
David,
thank you very much for the feedback.
see comments inline
On Thu, Jan 5, 2017 at 6:05 PM, David Ries <ries@jovalcm.commailto:ries@jovalcm.com> wrote:
Hi Jerome,
This is very exciting. Automated generation of high-quality CVE OVAL would be very valuable to the community and I’d love to help.
JA> Happy if that is seen as valuable
I have spent some time working on this problem, but I didn’t take this approach (based on file/versions added by KB) and I’m hoping this works!
JA> I just reverse engineered the latest OVAL Vulnerability Definitions published after the 'Patch Tuesday' and automated the process of generation
JA> PoC under tests, but for Microsoft Windows Products it currently works ok (I'm comparing the ones I autogenerate vs the latest ones published by the community)
JA> That just seems to reduce the time for having a Definition for a CVE/KBs from up to a month (as per my observations) to just minutes after the CVE (with the CPEs list) is released. Note that, at this stage, for the current scope (and due to hardcoding*), a MS- page could be enough as an input.
JA> Note that the PoC currently heavily use Hardcoding* (which is important for your following point)
Automating Inventory
You didn’t propose an automated solution for product/OS inventory, noting that a ton of these have already been created and contributed to the repository. I don’t know how often new inventory definitions are required, but if it turns out that we need an automated way to create these going forward as new MS products, service packs, etc are released, I think we may have one to contribute.
JA> Help is always welcome. I would see many ways for automation in this area. (i.e. a Lab for VMs with an MSDN account and some simple code for auto-install/update and listing of settings/values like in the registry, etc. - I used to do that to maintain an opcode database)
JA> Going further would need a software collection (http://www.nsrl.nist.gov/ maybe) if we would like to apply the same kind of automated process to any kind of windows-based software (from other vendors than Microsoft). The softwares characteristics* (names*/settings/values/files versions/registry keys, etc.) could be captured automatically (if not provided with SWID... or by the CVE, CVRF/CSAF...) on a VM.
JA> Note here I used to maintain a collection of vulnerable softwares binaries, like the one now on exploit-db
JA> Going further, if you allow me...
JA> The same automated process could be applied to Unix/Linux world, and I guess that will be easier with the packages
JA> The process described here is applicable - now - because of the 'Big Data' (dataset) available (thanks to the work of the community over the past few years). And one could envision to replace the hardcoding* using AI (see https://www.whitehouse.gov/sites/whitehouse.gov/files/documents/Artificial-Intelligence-Automation-Economy.PDF )
JA> I currently believe that we will live soon in a new world (Digital Age Ref.https://www.whitehouse.gov/sites/default/files/docs/cybersecurity_report.pdf ) with all IoTs around us, with these endpoints having enough computing power embedded to perform automated checks on themselves (asset software inventory, auto-update through M2M, etc.). Given that we will lack human resources to manage these (too many) (not secure by design) IoTs endpoints with the methods (think SACM) and softwares we have been using over the past decades, if we want to resolve challenges like this http://www.computerworld.com/article/3154348/security/ftc-sets-25-000-prize-for-automatic-iot-patching.html we need to standardize and automate, and review our thinking.
JA> As of now I would think of a software based solution/function injectable into the IoT (if not the processor yet), that would autonomously use our 'Big Data' to manage/secure itself. (technically not so hard)
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over time. Microsoft patches sometimes add and remove files altogether and also can supersede other patches. For example suppose the following patches are released:
- On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
- On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
- On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that was built in March based on KB 1 return a false positive? Does that make sense? I’m not sure this will be an issue in practice, but it seems like it would be.
JA> Right now, I can't answer that. IMHO, could be valid, while I doubt that would be a short-term issue (assuming that the Vulnerability Check Definitions are not really expected to have a long lifetime/period of effective use). The community of OVAL users could provide feedback
Best,
David
On Jan 1, 2017, at 12:50 PM, Jerome Athias <athiasjerome@GMAIL.COMmailto:athiasjerome@gmail.com> wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for now.
Feedback appreciated.
Thank you
Have a good one
...<CVE-2016-7219.txt><Automated Generation of OVAL Vulnerability Definitions-Microsoft Windows-Jerome Athias-DRAFT.pdf>_______________________________________________
OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.orgmailto:OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
David E. Ries
Co-Founder, Business Development
ries@jovalcm.commailto:ries@jovalcm.com
<image001.jpg>http://jovalcm.com/
<image002.jpg>https://www.facebook.com/jovalcm<image002.jpg>https://www.linkedin.com/company/joval-continuous-monitoring
...
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
David E. Ries
Co-Founder, Business Development
ries@jovalcm.commailto:ries@jovalcm.com
[Joval Continuous Monitoring]http://jovalcm.com/
[Facebook]https://www.facebook.com/jovalcm[Linkedin]https://www.linkedin.com/company/joval-continuous-monitoring
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
...
Hi,
So, if it's really something of interest (? otherwise please stop me now),
I rushed a bit for testing version Alpha on Patch Tuesday...
With very limited time for it and few minor last minutes changes, I would
say that results were acceptable, and interesting lessons learnt.
Now, first thing that gave me headaches is:
- Non Standardization of OVAL Inventory Definitions Titles/comments
So this is not a negative remark, while I know that they are just
"comments", that people spent time/effort into them, and are not intended
by OVAL to be used in my way.
(In case I missed something, please kindly do let me know.)
Anyway, I will give some examples (see below), and hopefully you will
understand the number of transformations/regex I currently have to use for
a matching function.
Which triggers this question for the community:
Is there any objection to a review/Standardization/update of the Titles of
OVAL Windows Inventory Definitions?
(I just don't want to break others tools in case they would use these
somehow)
Now, if no objection; we (or I) could come with one guideline/update for
this. (that could be based on the CPE specification or/and the "Microsoft
convention")
issues: SP vs Service Pack, x86 vs 32bit vs 32 bits vs 32-bit vs (32 bits)
vs ..., same for x64, x64 before SP vs x64 after SP, etc., etc. in various
orders
Microsoft Windows 10 (32-bit) is installed
Microsoft Windows 10 (64-bit) is installed
Microsoft Windows 10 (x86) is installed
Microsoft Windows 10 (x64) is installed
Microsoft Windows 10 Version 1511 (32-bit) is installed
Microsoft Windows 10 Version 1511 (x86) is installed
Microsoft Windows 7 (32-bit) Service Pack 1 is installed
Microsoft Windows Server 2003 SP1 (x64) is installed
Microsoft Windows Server 2008 R2 x64 Edition is installed
Microsoft Windows Server 2012 (64-bit) is installed
Microsoft Windows 7 (32-bit) Service Pack 1 Release Candidate is installed
Microsoft Windows XP (x86) SP3 is installed
Microsoft Windows XP x64 Edition SP2 is installed
Microsoft Windows 7 x64 Edition is installed
Microsoft Windows 8 (x64) is installed
Microsoft Windows 8 Release Preview (64 bit) is installed
Microsoft Windows Server 2003 (ia64) SP2 is installed
On Thu, Jan 5, 2017 at 6:05 PM, David Ries ries@jovalcm.com wrote:
Hi Jerome,
This is very exciting. Automated generation of high-quality CVE OVAL would
be very valuable to the community and I’d love to help.
I have spent some time working on this problem, but I didn’t take this
approach (based on file/versions added by KB) and I’m hoping this works!
Automating Inventory
You didn’t propose an automated solution for product/OS inventory, noting
that a ton of these have already been created and contributed to the
repository. I don’t know how often new inventory definitions are required,
but if it turns out that we need an automated way to create these going
forward as new MS products, service packs, etc are released, I think we may
have one to contribute.
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over
time. Microsoft patches sometimes add and remove files altogether and also
can supersede other patches. For example suppose the following patches are
released:
- On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
- On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
- On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new
file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that
was built in March based on KB 1 return a false positive? Does that make
sense? I’m not sure this will be an issue in practice, but it seems like it
would be.
Best,
David
On Jan 1, 2017, at 12:50 PM, Jerome Athias <athiasjerome@GMAIL.COM
athiasjerome@gmail.com> wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for
now.
Feedback appreciated.
Thank you
Have a good one
...<CVE-2016-7219.txt><Automated Generation of OVAL Vulnerability Definitions-Microsoft Windows-Jerome Athias-DRAFT.pdf>_____________
OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_
developer_lists.cisecurity.org
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com
[image: Joval Continuous Monitoring] http://jovalcm.com
[image: Facebook] https://www.facebook.com/jovalcm [image: Linkedin]
https://www.linkedin.com/company/joval-continuous-monitoring
...
Hi Jerome,
I’d support standardizing the titles of inventory definitions. If we’re going to do it, it would be nice to also standardize the metadata/affected/platform and metadata/affected/product values. Then, we could base the inventory titles on these (e.g. “[product | platform] is installed.") and address two related issues at once.
Platforms and products are probably added to often to make it practical for these to be enumerations. However, we could maintain a list in the repo and add a repo contribution guideline specifying that an appropriate value should be selected from the list, if one exists. If not, a new value should be added to the list in a format matching the most closely related existing list value.
Thoughts?
-David
On Jan 12, 2017, at 11:13 PM, Jerome Athias athiasjerome@GMAIL.COM wrote:
Hi,
So, if it's really something of interest (? otherwise please stop me now),
I rushed a bit for testing version Alpha on Patch Tuesday...
With very limited time for it and few minor last minutes changes, I would say that results were acceptable, and interesting lessons learnt.
Now, first thing that gave me headaches is:
- Non Standardization of OVAL Inventory Definitions Titles/comments
So this is not a negative remark, while I know that they are just "comments", that people spent time/effort into them, and are not intended by OVAL to be used in my way.
(In case I missed something, please kindly do let me know.)
Anyway, I will give some examples (see below), and hopefully you will understand the number of transformations/regex I currently have to use for a matching function.
Which triggers this question for the community:
Is there any objection to a review/Standardization/update of the Titles of OVAL Windows Inventory Definitions?
(I just don't want to break others tools in case they would use these somehow)
Now, if no objection; we (or I) could come with one guideline/update for this. (that could be based on the CPE specification or/and the "Microsoft convention")
issues: SP vs Service Pack, x86 vs 32bit vs 32 bits vs 32-bit vs (32 bits) vs ..., same for x64, x64 before SP vs x64 after SP, etc., etc. in various orders
Microsoft Windows 10 (32-bit) is installed
Microsoft Windows 10 (64-bit) is installed
Microsoft Windows 10 (x86) is installed
Microsoft Windows 10 (x64) is installed
Microsoft Windows 10 Version 1511 (32-bit) is installed
Microsoft Windows 10 Version 1511 (x86) is installed
Microsoft Windows 7 (32-bit) Service Pack 1 is installed
Microsoft Windows Server 2003 SP1 (x64) is installed
Microsoft Windows Server 2008 R2 x64 Edition is installed
Microsoft Windows Server 2012 (64-bit) is installed
Microsoft Windows 7 (32-bit) Service Pack 1 Release Candidate is installed
Microsoft Windows XP (x86) SP3 is installed
Microsoft Windows XP x64 Edition SP2 is installed
Microsoft Windows 7 x64 Edition is installed
Microsoft Windows 8 (x64) is installed
Microsoft Windows 8 Release Preview (64 bit) is installed
Microsoft Windows Server 2003 (ia64) SP2 is installed
On Thu, Jan 5, 2017 at 6:05 PM, David Ries <ries@jovalcm.com mailto:ries@jovalcm.com> wrote:
Hi Jerome,
This is very exciting. Automated generation of high-quality CVE OVAL would be very valuable to the community and I’d love to help.
I have spent some time working on this problem, but I didn’t take this approach (based on file/versions added by KB) and I’m hoping this works!
Automating Inventory
You didn’t propose an automated solution for product/OS inventory, noting that a ton of these have already been created and contributed to the repository. I don’t know how often new inventory definitions are required, but if it turns out that we need an automated way to create these going forward as new MS products, service packs, etc are released, I think we may have one to contribute.
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over time. Microsoft patches sometimes add and remove files altogether and also can supersede other patches. For example suppose the following patches are released:
On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that was built in March based on KB 1 return a false positive? Does that make sense? I’m not sure this will be an issue in practice, but it seems like it would be.
Best,
David
On Jan 1, 2017, at 12:50 PM, Jerome Athias <athiasjerome@GMAIL.COM mailto:athiasjerome@gmail.com> wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for now.
Feedback appreciated.
Thank you
Have a good one
...<CVE-2016-7219.txt><Automated Generation of OVAL Vulnerability Definitions-Microsoft Windows-Jerome Athias-DRAFT.pdf>_______________________________________________
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
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com mailto:ries@jovalcm.com
http://jovalcm.com/
https://www.facebook.com/jovalcm https://www.linkedin.com/company/joval-continuous-monitoring
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com mailto:ries@jovalcm.com
http://jovalcm.com/
https://www.facebook.com/jovalcm https://www.linkedin.com/company/joval-continuous-monitoring
...
Hi Jerome,
I think I speak for most of the community when I say that rapid/automated generation of high-quality MS CVE content is very much of interest. The need has been discussed on the last several OVAL Board calls. Many organizations have volunteered to work on this, but no one has yet come up with an acceptable solution.
So yes, if your approach works, we really want it!!
Speaking for myself, I am concerned that the current proposal will not create content that holds up over time.
Most current CVE definitions check for the existence of the specific files and/or other configuration parameters that positively indicate you have the vulnerability. The current proposal creates content that checks for the file names/versions contained in the first patch that is released to address the CVE. That should work… until subsequent patches are released that supersede the first patch. And, MS does this all the time. I think that over time, this content will produce false positives whenever a superseding patch changes the file name or elevates the version to a major, minor or build version not contained in the original file set.
Or, maybe I’m overthinking it and this doesn’t happen much in practice.
How difficult would it be for you to generate a set of all the MS CVEs from 1/1/2015 to present? Then, we could all do some testing to be sure.
-David
On Jan 12, 2017, at 11:13 PM, Jerome Athias athiasjerome@GMAIL.COM wrote:
Hi,
So, if it's really something of interest (? otherwise please stop me now),
I rushed a bit for testing version Alpha on Patch Tuesday...
With very limited time for it and few minor last minutes changes, I would say that results were acceptable, and interesting lessons learnt.
Now, first thing that gave me headaches is:
- Non Standardization of OVAL Inventory Definitions Titles/comments
So this is not a negative remark, while I know that they are just "comments", that people spent time/effort into them, and are not intended by OVAL to be used in my way.
(In case I missed something, please kindly do let me know.)
Anyway, I will give some examples (see below), and hopefully you will understand the number of transformations/regex I currently have to use for a matching function.
Which triggers this question for the community:
Is there any objection to a review/Standardization/update of the Titles of OVAL Windows Inventory Definitions?
(I just don't want to break others tools in case they would use these somehow)
Now, if no objection; we (or I) could come with one guideline/update for this. (that could be based on the CPE specification or/and the "Microsoft convention")
issues: SP vs Service Pack, x86 vs 32bit vs 32 bits vs 32-bit vs (32 bits) vs ..., same for x64, x64 before SP vs x64 after SP, etc., etc. in various orders
Microsoft Windows 10 (32-bit) is installed
Microsoft Windows 10 (64-bit) is installed
Microsoft Windows 10 (x86) is installed
Microsoft Windows 10 (x64) is installed
Microsoft Windows 10 Version 1511 (32-bit) is installed
Microsoft Windows 10 Version 1511 (x86) is installed
Microsoft Windows 7 (32-bit) Service Pack 1 is installed
Microsoft Windows Server 2003 SP1 (x64) is installed
Microsoft Windows Server 2008 R2 x64 Edition is installed
Microsoft Windows Server 2012 (64-bit) is installed
Microsoft Windows 7 (32-bit) Service Pack 1 Release Candidate is installed
Microsoft Windows XP (x86) SP3 is installed
Microsoft Windows XP x64 Edition SP2 is installed
Microsoft Windows 7 x64 Edition is installed
Microsoft Windows 8 (x64) is installed
Microsoft Windows 8 Release Preview (64 bit) is installed
Microsoft Windows Server 2003 (ia64) SP2 is installed
On Thu, Jan 5, 2017 at 6:05 PM, David Ries <ries@jovalcm.com mailto:ries@jovalcm.com> wrote:
Hi Jerome,
This is very exciting. Automated generation of high-quality CVE OVAL would be very valuable to the community and I’d love to help.
I have spent some time working on this problem, but I didn’t take this approach (based on file/versions added by KB) and I’m hoping this works!
Automating Inventory
You didn’t propose an automated solution for product/OS inventory, noting that a ton of these have already been created and contributed to the repository. I don’t know how often new inventory definitions are required, but if it turns out that we need an automated way to create these going forward as new MS products, service packs, etc are released, I think we may have one to contribute.
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over time. Microsoft patches sometimes add and remove files altogether and also can supersede other patches. For example suppose the following patches are released:
On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that was built in March based on KB 1 return a false positive? Does that make sense? I’m not sure this will be an issue in practice, but it seems like it would be.
Best,
David
On Jan 1, 2017, at 12:50 PM, Jerome Athias <athiasjerome@GMAIL.COM mailto:athiasjerome@gmail.com> wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for now.
Feedback appreciated.
Thank you
Have a good one
...<CVE-2016-7219.txt><Automated Generation of OVAL Vulnerability Definitions-Microsoft Windows-Jerome Athias-DRAFT.pdf>_______________________________________________
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
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com mailto:ries@jovalcm.com
http://jovalcm.com/
https://www.facebook.com/jovalcm https://www.linkedin.com/company/joval-continuous-monitoring
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com mailto:ries@jovalcm.com
http://jovalcm.com/
https://www.facebook.com/jovalcm https://www.linkedin.com/company/joval-continuous-monitoring
...
Hi Jerome,
I think I speak for most of the community when I say that rapid/automated
generation of high-quality MS CVE content is very much of interest. The
need has been discussed on the last several OVAL Board calls. Many
organizations have volunteered to work on this, but no one has yet come up
with an acceptable solution.
So yes, if your approach works, we really want it!!
JA> ok, good to know
Speaking for myself, I am concerned that the current proposal will not
create content that holds up over time.
Most current CVE definitions check for the existence of the specific files
and/or other configuration parameters that positively indicate you have the
vulnerability. The current proposal creates content that checks for the
file names/versions contained in the first patch that is released to
address the CVE. That should work… until subsequent patches are released
that supersede the first patch. And, MS does this all the time. I think
that over time, this content will produce false positives whenever a
superseding patch changes the file name or elevates the version to a major,
minor or build version not contained in the original file set.
Or, maybe I’m overthinking it and this doesn’t happen much in practice.
JA> I understand the concern.
JA> Yes, that could happen
JA> Often, I don't think so -for now-, (and sorry it's difficult to
explain) because:
A vulnerability basically happens if:
- Something (the code) is wrong
- Something is missing
Most of the cases would be 1), meaning that the code needs to be changed
(file update) or removed (file deleted, which I think Alexander said the
definition would work... and which probably also means that another file
would be updated or added* (the definition could be based on the new file))
For 2), your previously described scenario is "On March 1st, KB 1 adds
foo.dll v1 to address CVE-FOO": this is very unlikely that a vulnerability
would be fixed just by adding 1 file (another file2 would use the added*
file so file2 would change)
JA> I would have to investigate further to resolve the concern, but I think
tracking this would be possible (i.e. in XORCISM)
How difficult would it be for you to generate a set of all the MS CVEs
from 1/1/2015 to present? Then, we could all do some testing to be sure.
JA> In practice, I think not -too much- difficult. BUT, I would prefer not
to do that now with the Alpha version.
JA> I think that I have all the needed functions of a puzzle that I need to
reassemble (reorganize the algorithm/pseudo code) due to lessons learnt (no
CVE/CPEs info at time of MS Patch Tuesday release, etc.)
JA> Also the scraping just missed few things. (easy to fix, but
availability of an API would be far more elegant and reliable)
JA> For now the code is just horrible (kind of "when i started coding this,
only god and me knew what i was doing now, god only knows - Joe the
progrHammer"), due for example to the non-standard Inventory Definitions
Titles. I would prefer to fix the root causes than coming up with complex
code
JA> Overall, I think it's possible after PoC, and ultimately (for now), I
would hope that we could produce Vulnerability detection data (OVAL
Vulnerability Definition) automatically based on Vulnerability description
information (i.e. CVE/CPEs/CVRF...) that could be both pushed automatically
(i.e. as STIX package (one day in JSON maybe...)) for triggering a COA
like Vulnerability
assessment.
-David
On Jan 12, 2017, at 11:13 PM, Jerome Athias <athiasjerome@GMAIL.COM
athiasjerome@gmail.com> wrote:
Hi,
So, if it's really something of interest (? otherwise please stop me now),
I rushed a bit for testing version Alpha on Patch Tuesday...
With very limited time for it and few minor last minutes changes, I would
say that results were acceptable, and interesting lessons learnt.
Now, first thing that gave me headaches is:
- Non Standardization of OVAL Inventory Definitions Titles/comments
So this is not a negative remark, while I know that they are just
"comments", that people spent time/effort into them, and are not intended
by OVAL to be used in my way.
(In case I missed something, please kindly do let me know.)
Anyway, I will give some examples (see below), and hopefully you will
understand the number of transformations/regex I currently have to use for
a matching function.
Which triggers this question for the community:
Is there any objection to a review/Standardization/update of the Titles
of OVAL Windows Inventory Definitions?
(I just don't want to break others tools in case they would use these
somehow)
Now, if no objection; we (or I) could come with one guideline/update for
this. (that could be based on the CPE specification or/and the "Microsoft
convention")
issues: SP vs Service Pack, x86 vs 32bit vs 32 bits vs 32-bit vs (32 bits)
vs ..., same for x64, x64 before SP vs x64 after SP, etc., etc. in various
orders
Microsoft Windows 10 (32-bit) is installed
Microsoft Windows 10 (64-bit) is installed
Microsoft Windows 10 (x86) is installed
Microsoft Windows 10 (x64) is installed
Microsoft Windows 10 Version 1511 (32-bit) is installed
Microsoft Windows 10 Version 1511 (x86) is installed
Microsoft Windows 7 (32-bit) Service Pack 1 is installed
Microsoft Windows Server 2003 SP1 (x64) is installed
Microsoft Windows Server 2008 R2 x64 Edition is installed
Microsoft Windows Server 2012 (64-bit) is installed
Microsoft Windows 7 (32-bit) Service Pack 1 Release Candidate is installed
Microsoft Windows XP (x86) SP3 is installed
Microsoft Windows XP x64 Edition SP2 is installed
Microsoft Windows 7 x64 Edition is installed
Microsoft Windows 8 (x64) is installed
Microsoft Windows 8 Release Preview (64 bit) is installed
Microsoft Windows Server 2003 (ia64) SP2 is installed
On Thu, Jan 5, 2017 at 6:05 PM, David Ries ries@jovalcm.com wrote:
Hi Jerome,
This is very exciting. Automated generation of high-quality CVE OVAL
would be very valuable to the community and I’d love to help.
I have spent some time working on this problem, but I didn’t take this
approach (based on file/versions added by KB) and I’m hoping this works!
Automating Inventory
You didn’t propose an automated solution for product/OS inventory, noting
that a ton of these have already been created and contributed to the
repository. I don’t know how often new inventory definitions are required,
but if it turns out that we need an automated way to create these going
forward as new MS products, service packs, etc are released, I think we may
have one to contribute.
Is File Version Comparison Sufficient Over Time?
I wonder if using the file/versions in the KB/patch is sufficient over
time. Microsoft patches sometimes add and remove files altogether and also
can supersede other patches. For example suppose the following patches are
released:
- On March 1st, KB 1 adds foo.dll v1 to address CVE-FOO
- On April 1st, KB 2 updates bar.dll v1 to v2 to address CVE-BAR
- On May 1st, KB 3 supersedes KB 1, removing foo.dll and adding a new
file foo2.dll v1
Once KB 3 is installed in May, won’t the OVAL definition for CVE-FOO that
was built in March based on KB 1 return a false positive? Does that make
sense? I’m not sure this will be an issue in practice, but it seems like it
would be.
Best,
David
On Jan 1, 2017, at 12:50 PM, Jerome Athias <athiasjerome@GMAIL.COM
athiasjerome@gmail.com> wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for
now.
Feedback appreciated.
Thank you
Have a good one
...<CVE-2016-7219.txt><Automated Generation of OVAL Vulnerability Definitions-Microsoft Windows-Jerome Athias-DRAFT.pdf>_____________
OVAL_Developer mailing list
OVAL_Developer@lists.cisecurity.org
http://lists.cisecurity.org/mailman/listinfo/oval_developer_
lists.cisecurity.org
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com
[image: Joval Continuous Monitoring] http://jovalcm.com/
[image: Facebook] https://www.facebook.com/jovalcm [image: Linkedin]
https://www.linkedin.com/company/joval-continuous-monitoring
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com
[image: Joval Continuous Monitoring] http://jovalcm.com
[image: Facebook] https://www.facebook.com/jovalcm [image: Linkedin]
https://www.linkedin.com/company/joval-continuous-monitoring
...
Hi Jerome,
That’s terrific. I know you’ve put a lot of work into this and I am excited about it.
Once you are happy with the Alpha version, I hope you can generate the historical (1/1/2015-now) MS CVE definitions for general review. Speaking only for myself, I want to go through that community review / qa to ensure the script-generated, patch-file-oriented definitions hold up over time before adding any of them to the repo.
-David
On Jan 13, 2017, at 10:31 AM, Jerome Athias athiasjerome@gmail.com wrote:
How difficult would it be for you to generate a set of all the MS CVEs from 1/1/2015 to present? Then, we could all do some testing to be sure.
JA> In practice, I think not -too much- difficult. BUT, I would prefer not to do that now with the Alpha version.
David E. Ries
Co-Founder, Business Development
ries@jovalcm.com mailto:ries@jovalcm.com
http://jovalcm.com/
https://www.facebook.com/jovalcm https://www.linkedin.com/company/joval-continuous-monitoring
...
Hi,
So just investigating a case here.
Even if, at moment of writing, I think it was a mistake in definition
oval:org.cisecurity:def:1487
https://ovaldb.altx-soft.ru/Definition.aspx?id=oval:org.cisecurity:def:1487
In oval:org.cisecurity:def:1487
https://ovaldb.altx-soft.ru/Definition.aspx?id=oval:org.cisecurity:def:1487
CVE-2016-7215
(MS16-135)
For Microsoft Windows 10 Version 1511
The test is Check if Win32k.sys version is less than 10.0.10586.20
It looks like ok as per the rest of the Definition (all tests on
Win32k.sys), and the correct (see below) version number.
However, looking (today (does this matter?)) at 3198586
https://support.microsoft.com/help/3198586 Cumulative Update for Windows
10 Version 1511: November 8, 2016
Especially the File Information in the CSV provided by Microsoft:
Win32k.sys 10.0.10586.20 89,600 24-Nov-15
Win32kbase.sys 10.0.10586.672 1,151,488 25-Oct-16
Win32kfull.sys 10.0.10586.672 2,972,672 25-Oct-16
Note: The test does not target the latest modified "Windows Kernel File"
Problem:
While generating (today (does this matter?)) a Definition for CVE-2016-7211
(MS16-123) (not yet in the repo? ;)) with my tool
I found in 3192441 https://support.microsoft.com/help/3192441 Cumulative
update for Windows 10 Version 1511: October 11, 2016 CSV:
Win32k.sys 10.0.10586.20 115,200 24-Nov-15
Win32kbase.sys 10.0.10586.589 1,387,520 7-Sep-16
Win32kfull.sys 10.0.10586.633 3,589,120 5-Oct-16
So same Version/Date for Win32k.sys than for an older
Vulnerability/Definition.
So, at the moment, I believe it is just an error in
oval:org.cisecurity:def:1487
https://ovaldb.altx-soft.ru/Definition.aspx?id=oval:org.cisecurity:def:1487
(wrong
target file for the test), which is worth highlighting (cause resulting in
false positive)/explaining IMHO.
Or, could be, potentially? (please explain it to me!) an example of your
concern?
(and the headaches continue...)
On Fri, Jan 13, 2017 at 7:31 PM, Jerome Athias athiasjerome@gmail.com
wrote:
Hi Jerome,
Speaking for myself, I am concerned that the current proposal will not
create content that holds up over time.
Most current CVE definitions check for the existence of the specific
files and/or other configuration parameters that positively indicate you
have the vulnerability. The current proposal creates content that checks
for the file names/versions contained in the first patch that is released
to address the CVE. That should work… until subsequent patches are released
that supersede the first patch. And, MS does this all the time. I think
that over time, this content will produce false positives whenever a
superseding patch changes the file name or elevates the version to a major,
minor or build version not contained in the original file set.
Or, maybe I’m overthinking it and this doesn’t happen much in practice.
JA> I understand the concern.
JA> Yes, that could happen
JA> Often, I don't think so -for now-, (and sorry it's difficult to
explain) because:
A vulnerability basically happens if:
- Something (the code) is wrong
- Something is missing
Most of the cases would be 1), meaning that the code needs to be changed
(file update) or removed (file deleted, which I think Alexander said the
definition would work... and which probably also means that another file
would be updated or added* (the definition could be based on the new file))
For 2), your previously described scenario is "On March 1st, KB 1 adds
foo.dll v1 to address CVE-FOO": this is very unlikely that a vulnerability
would be fixed just by adding 1 file (another file2 would use the added*
file so file2 would change)
JA> I would have to investigate further to resolve the concern, but I
think tracking this would be possible (i.e. in XORCISM)
...
One quick update.
The API approach would be the way to go (in the sense that scraping is
bad), while it simplifies the task (proper identification of the
Platforms/Products) (and I salute Microsoft for the effort)
Unfortunately for us, the (imho) principal weakness (in a more global
scope) of CVRF (hopefully to be fixed in CSAF) and CVE (security by
obscurity? maybe to change with the new web form) for our automation (M2M)
efforts is when the "exposed/affected component" (e.g. executable
filename, uri/parameter, file/function, protocol/port...) is not specified
or provided in a detailed/structured way.
Known issue for years (where AVDL or IVIL like languages/formats would be
more efficient)
On Thu, Jan 5, 2017 at 6:36 AM, Hassan Sultan hsultan@thefroid.net wrote:
On Sun, 01 Jan 2017 12:50:38 -0600, Jerome Athias athiasjerome@gmail.com
wrote:
Greetings,
And Happy New OVALYear!
I spent few days looking at automatically generating OVAL
vulnerability Definitions, first for Microsoft products.
At time of writing, I successfully wrote initial source code to
automatically collect all the information needed to do so, providing
just a CVE number as an input.
(with my vacations coming to the end, I can't clean/optimize and
complete/release the code right now to write the XML using the
collected information. But this would not take too long. So hopefully
ready for end of this month)
I'm just interested to know if it's something you guys already doing?
Just sharing some Draft documentation and some tool testing outputs for
now.
Feedback appreciated.
Hey Jerome, that's interesting. I'm wondering, are you using the REST API
at https://blogs.technet.microsoft.com/msrc/2016/11/08/furtheri
ng-our-commitment-to-security-updates/ to get Microsoft CVRF data ?
The CVRF for each bulletin gives a direct link to the download page for
the patch, and once downloaded you could uncompress the patch, and see what
files are located inside (and their version / branch).
Cheers,
Hassan
...