Tag Archives: open source

Weekly Security News for the Week Ending March 20, 2020

Senate Kicks the Can Down The Road Again With FISA Renewal

Last week it looked like Congress was going to renew the parts of the Foreign Intelligence Surveillance Act that DID EXPIRE last weekend.  But Congress being Congress, they didn’t.  On Monday the Senate agreed to kick the can down the  road for 77  days.  Now the House has to agree.  In the meantime, I am not sure what the NSA is doing about those expired provisions and they only plan to kick the can down the road on two of the three expired provisions.  In fairness, Trump wants to reign in the Intelligence Community since he doesn’t trust them and never has.  This could work to the advantage of the privacy advocates.  Source: Reuters

Covid-19 Web Site President Said Google Would Bring Online Monday is Online But Not Like he Said

Google/Alphabet subsidiary Verily launched its Project Baseline Coronavirus website, but it is not national, it only covers two counties in the San Francisco Bay area.  It was supposed to allow people to make appointments to get tested, but the few slots that were available filled up instantly.  Only people living in those two counties are even allowed to use the site.

Google says that they are working on a nationwide INFORMATION ONLY site and it will be released sometime in the future.  Source: Bleeping Computer

Open Source Vulnerabilities Surge in 2019

Some people say that open source software is more secure.

Reality is a little different than that.

In 2019 DISCLOSED open source vulnerabilities surged from 4,000 to 6,000 last year.  The good news is that the open source community is good about fixing the vulnerabilities once they are found.  85% of the vulnerabilities  have a fix once they are responsibly disclosed.

Bottom line, make sure that you have an effective open source software patching program to keep your company safe. Source: Help Net Security

U.S. Census Figures Coronavirus Will Be Over in Two Weeks

The Census, that every 10 year event, was supposed to start this week.  But there is kind of an issue.  I think there is some kind of virus going around.  Part of how the Census works is that Census workers go around collecting information from people.  Given the current situation, (a) Census workers are probably not going to be willing to risk their health for a few bucks, (b) people that they visit are likely not going to let them in the door or (c) some other less than nice thing might happen.

So what did the geniuses at the Census  bureau decide to do?  They decided that they are going to send out Census workers in 13 days on April 1st. WHAT, EXACTLY, DO THEY EXPECT TO BE DIFFERENT IN 13 DAYS?

Ya gotta wonder about those folks in Washington.  Source: Reuters

OCR Lifts Penalties For Telehealth Use During Covid-19

Its all hands on deck.  HIPAA has a number of provisions that allow a healthcare provider to bypass certain HIPAA rules.  A pandemic is not one of those options.  Of course since the Feds make the rules, they can change them.  In light of the current situation, HHS says that they will not penalize Covered Entities for using telehealth providers who are not fully HIPAA compliant.  They are not saying using those providers is legal;  they are just saying, given the circumstances, they are not going to go after providers who do so.  This will allow providers to use apps like Facetime or Google Chat to diagnose patients instead making them come into the office and potentially infect dozens of other people.  It seems like a reasonable trade off.  Source: HealthIT Security

Open Source – The New Attack Vector

There are people who think open source is the holy grail of software,  I am not one of them.  Apparently hackers agree with me.  So does the Department of Defense.  They have even coined a term – SCRM or Supply Chain Risk Management.

Bottom line, developers need to understand that there is a war out there and they are the target.  According to Sonatype, the open source tools and governance company, said that the use of vulnerable open source components is up by 120% over the last 12 months,

Sonatype estimates that there are 1.3 million – yes, million – vulnerabilities in open source software components that are not recorded in the National Vulnerability Database managed by NIST.

Sonatype estimates that the average enterprise downloads 170,000 source components a year of which possibly 1 out of 8 of those have some form of vulnerability.  Sometimes those vulnerabilities get exploited in as little as 3 days.

Developers are still downloading vulnerable versions of Apache Struts (as in Equifax breach).  About 80,000 times every month.

Downloads of a vulnerable version of the Spring Framework was around 85,000 a month last year;  this year it is still 72,000 a month.

To add insult to injury, hackers are starting to inject vulnerabilities directly into some open source packages.  Done cleverly, such a logic bomb might never be discovered.

Point is, still a HUGE problem.

So what do you need to do?

#1 – Admit that open source software is far from bug free – even hugely popular packages like Apache Struts.

#2 – Create a SCRM program.  The larger the open source software package is, the more difficult it is to make sure that it is safe.  

#3 – Consider using automated tools to detect vulnerabilities.  Some of the tools are free and others are very expensive, and all of them change the development process.  Some of them are built into the software tools that developers are already using.

#4 – Create a process for finding out about patch availability.  Unfortunately,  except for the most popular open source packages, they are never patched, so you are pretty much on your own.

#5 – Treat open source packages just like code you develop when it comes to code reviews and testing.  The only difference that you can’t influence the development process.

Information for this post came from The Register.

Open Source is NOT Bug Free

Linux

There are those in the open source software fan world that suggest that open source (and typically free) software is best because since the source code is available, people can look for bugs and fix them, resulting is bug free software.

The reality is not quite so simple.

While this statement is technically true, it is not true in practice.  Time and time again we run into very popular open source software with bugs – software like Open SSL which is installed on millions of computers.

That also does not mean that open source software is bad or overly buggy. It just means that it is software and all software needs to be validated.

AND, it also means that even if software is tested, it is not bug free.

OK, with that preamble, what are we dealing with today?

Google has an internal hacking team called Project Zero and they try to hack all kinds of software – including but not limited to Google’s own software.  This week team member Andrey Konovalov was playing with the USB drivers in the Linux kernel.

When someone mentions the words BUG and KERNEL in the same sentence, it should get your attention.  The kernel is the most privileged and most sensitive part of any operating system.

Andrey identified 14 bugs in the USB drivers that have been assigned bug ID numbers so far.  He has also requested another 7 numbers for additional vulnerabilities that he has identified.  On top of this, he says there are probably another 20 that have not been fully researched yet.  That puts the number of likely bugs in a very sensitive part of the Linux OS at around 40.

And remember, this is just in one part of the operating system.

So the next time someone tells you that open source means bug free, you can pull out a copy of this post.

Also, it is important to remember that Linux is an INCREDIBLY popular piece of open source software, used by hundreds of millions of people (It is the core of all Android phones).  If it is not bug free, is it reasonable to think that some other piece of open source software used by 10s of people IS bug free?  I don’t think so.

So, like with everything else, Caveat Emptor is appropriate response.

Information for this post came from Bleeping Computer and The Register.

OpenSSL: Here We Go Again

UPDATE:  The details are out.  The issue is that under certain circumstances, a hacker could get OpenSSL to accept an HTTPS certificate that is fraudulent.  This does not affect the major browsers, but rather the second and third tier software that uses SSL behind the scenes.  Likely, you don’t even know all the places that OpenSSL is used in your company.  For more information on OpenSSL’s somewhat checkered past (Heartbleed, Poodle, Freak, etc.), read this Symantec post.

OpenSSL, the open source toolkit that allows developers to support HTTPS and which is used in millions of pieces of software has announced that they are releasing a patch on Thursday.

The rather cryptic announcement, which is the way that OpenSSL works, just says that they are releasing a fix that corrects a single flaw and that flaw is classified as “high severity”.

OpenSSL has had a string of bug fixes over the last year.  The most well known of which, Heartbleed, is still being fixed by developers.  After Heartbleed, more people started looking at the code and found more bugs – some of which had been lurking there for 15 years.

While we won’t know the impact of this bug until Thursday, it raises the point that we should not assume that any given piece of open source software (or closed source software either) has been critically examined by millions of eyeballs.

In fact, until Heartbleed exploded, OpenSSL had exactly one full time employee shepherding it.  Of course, there were many other contributors to the project, but their level of participation is unknown.

After Heartbleed, the Linux Foundation (Linux uses OpenSSL), decided it was in their own self interest to fund  staff for OpenSSL.  Their funding allowed openSSL to add two more full time developers.  In addition, the Linux Foundation funded the Open Crypto Audit Project to do an audit of OpenSSL.

How long the Linux Foundation will fund these positions and whether the patch coming out Thursday was a result of the audit is unknown.

What we do know is that businesses need to understand their software supply chain (i.e. that they do use products that rely on OpenSSL, which products those are, whether the vulnerabilities are great enough that they need to mitigate the threat immediately – which may include shutting down systems like the OPM did last week with their eQIP system – not clear if there is any relation between these two events) and how they plan to fix the bug.

Since most open source software does not have dedicated development teams pushing out patches, businesses need to “fend for themselves”.  This is the downside of open source.  Most of the time all that means is that you may or may not get a new feature at a particular time.  In this case, it may be more serious.

This does not mean that you should not use open source.  It  is, however, a reminder to organizations that you  need to manage your software supply chain.  How well do you manage your software supply chain?

Source material for this article came from Infoworld and Networkworld.