topic Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020? in Getting Data In

How can we verify the patch that has been provided for the date time issue before 1/1/2020?

capesb — Tue, 03 Dec 2019 12:43:51 GMT

we were notified there is an issue with the recognition of 2 digit years in the Splunk code that requires an immediate patch. We need to know how to verify this patch is applied properly and going to be working properly come 1/1/2020
Link to issue: https://docs.splunk.com/Documentation/Splunk/8.0.0/ReleaseNotes/FixDatetimexml2020#More_information

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

richgalloway — Wed, 30 Sep 2020 03:14:29 GMT

To test the fix, try ingesting a file that contains the two-digit year "20". Use a test index, of course. You'll also need to set MAX_DAYS_HENCE in props.conf to a value that includes the date in the file (at least 30).

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

DavidHourani — Tue, 03 Dec 2019 14:00:48 GMT

Hi @capesb,

To confirm that the change has been made you need to be sure that your datetime.xml file matches the one in https://docs.splunk.com/Documentation/Splunk/8.0.0/ReleaseNotes/FixDatetimexml2020#More_information
And that you've restarted your Splunk instances after modification. As mentioned here :
https://docs.splunk.com/Documentation/Splunk/8.0.0/ReleaseNotes/FixDatetimexml2020#Download_an_updated_version_of_datetime.xml_and_apply_it_to_each_of_your_Splunk_platform_instances

OR that you are one of the bug free versions specified here :
https://docs.splunk.com/Documentation/Splunk/8.0.0/ReleaseNotes/FixDatetimexml2020#Upgrade_Splunk_platform_instances_to_a_version_with_an_updated_version_of_datetime.xml

On this blog you can find what exactly changed in the datetime.xml :
https://www.bleepingcomputer.com/news/security/splunk-faces-y2k-bug-like-problem-unless-patched/

Let me know if that helps.

Cheers,
David

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

woodcock — Tue, 03 Dec 2019 16:13:06 GMT

See here:
https://answers.splunk.com/answers/787821/how-can-we-verify-the-patch-that-has-been-provided.html

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

DavidHourani — Tue, 03 Dec 2019 16:17:06 GMT

@woodcock loop answer, can't go wrong there 😛

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

woodcock — Tue, 03 Dec 2019 16:19:35 GMT

Just keep clicking.

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

DavidHourani — Tue, 03 Dec 2019 16:22:48 GMT

lol almost there 😛

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

woodcock — Tue, 03 Dec 2019 17:23:03 GMT

Keep going!!!

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

capesb — Tue, 03 Dec 2019 18:21:28 GMT

thanks Rich and David, appreciate the feedback

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

DavidHourani — Tue, 03 Dec 2019 19:02:32 GMT

587 link clicks and still nothing...

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

jordanking1992 — Wed, 04 Dec 2019 19:19:49 GMT

Is there a query that can search the _raw events for sources that are using 2 digit years?

Re: How can we verify the patch that has been provided for the date time issue before 1/1/2020?

woodcock — Wed, 11 Dec 2019 18:35:33 GMT

You can use this search to find potentially problematic events. DISClAIMER: This is NOT a guarantee because we have no way to tell with SPL whether Indexers are using datetime.xml or proper Magic 6 settings. It will show you events that IF the indexers are using datetime.xml, will be broken without the fix.

index="*" AND sourcetype="*" AND timestartpos="*" earliest=-7d latest=now
| dedup punct sourcetype index
| eval timestr=substr(_raw, timestartpos+1, timeendpos-timestartpos)
| regex timestr="(((?:^|\D)\d{1,2}[-\/]\d{1,2}[-\/]19[^\d])|((?:^|\D)19[-\/]\d{1,2}[-\/]\d{1,2}[^\d])|((?:^|\D)\d{1,2}\s[-\/]\s\d{1,2}\s[-\/]\s19[^\d])|((?:^|\D)19\s[-\/]\s\d{1,2}\s[-\/]\s\d{1,2}[^\d])|((?:^|\D)([a-zA-Z]{3}[- \/]+\d{1,2}[- \/]+19[^:\d]))|((?:^|\D)19[- \/][a-zA-Z]{3}[- \/]\d{1,2}[^:\d])|((?:^|\D)\d{1,2}[- \/]+[a-zA-Z]{3}[- \/]+19[^:\d]))"
| table punct sourcetype index timestr time*pos _time _raw time*
| stats list(*) AS * BY index sourcetype

If this search returns nothing, then you have nothing to fix. Do note that this search will return the same results BEFORE and AFTER you deploy the fix. It only shows your potential risk, not your actual.