Archive for the ‘Security’ Category

Fedora Security Team FAD 2016

2016-03-02 Leave a comment

In a couple of weeks (March 11th) the Fedora Security Team will be meeting in Washington, D.C. to hack on training, security fixes, and other issues.  All Fedora contributors are welcome to stop by if you’re in the area.

All the information is available on the Security Team FAD 2016 wiki page.  Please go there and RSVP!

Securing email to Gmail

2015-12-22 3 comments

I’ve been working on securing my postfix configuration to enforce certificate validation and encryption on some known, higher-volume, or more sensitive connections between SMTP servers (port 25).

On many of the connections I’ve setup for secure transport there have been no problems (assuming proper TLS certificates are used).  Unfortunately Gmail™ has been a problem.  Sometimes it verifies and validates the certificate and other times it doesn’t… for days.

After conferring with Google Security I believe I’ve come up with a solution.  In my tls_policy file I’ve added the following:       secure ciphers=high protocols=TLSv1.2

So far this is working but I’ll continue to test.

If you run your own SMTP server and wish to maintain a secure connection with Gmail this is an easy way to enforce encryption as well as validate the certificate.  Of course this doesn’t protect the message while it’s being stored on the server or workstation (or on Google’s internal network).  To protect messages at rest (on a server) one should use GPG or S/MIME.  Using both TLS over the network between servers and GPG or S/MIME is beneficial to provide protection of the messages going over the Internet.


This configuration is applicable with the OpenSSL version shipped with CentOS 6/RHEL 6.  Implementing this on CentOS 7/RHEL7 or another flavor of Linux may require a different/better configuration.
The policy has been updated for CentOS 7/RHEL 7 which supports TLSv1.2 on Postfix.  Other services can also be setup similarly:    secure ciphers=high protocols=TLSv1.2    secure ciphers=high protocols=TLSv1.2    secure ciphers=high protocols=TLSv1.2    secure ciphers=high protocols=TLSv1.2

Encryption you don’t control is not a security feature

2015-09-23 Leave a comment

Catching up on my blog reading, this morning, led me to an article discussing Apple’s iMessage program and, specifically, the encryption it uses and how it’s implemented.  Go ahead and read the article; I’ll wait.

The TL;DR of that article is this: encryption you don’t control is not a security feature.  It’s great that Apple implemented encryption in their messaging software but since the user has no control over the implementation or the keys (especially the key distribution, management, and trust) users shouldn’t expect this type of encryption system to actually protect them.

For Apple, it’s all about UI and making it easy for the user.  In reality, what they’ve done is dumbed down the entire process and forced users to remain ignorant of their own security.  Many users applaud these types of “just make it work and make it pretty” interfaces but at the same time you end up with an uneducated user who doesn’t even realize that their data is at risk.  Honestly, it’s 2015… if you don’t understand information security… well, to quote my friend Larry “when you’re dumb, you suffer”.

Yes, that’s harsh.  But it’s time for people to wake up and take responsibility for their naked pictures or email messages being publicized.  I’m assuming most everyone makes at least a little effort toward physically securing their homes (e.g. locking doors and windows).  Why shouldn’t your data be any less protected?

In comparison, I’ll use Pidgin and OTR as an example of a better way to encrypt messaging systems.  OTR doesn’t use outside mechanisms for handling keys, it clearly displays whether or not a message is simply encrypted (untrusted) or whether you’ve verified the key, and it’s simple to use.

One thing I’ll say about Apple’s iMessage is that it at least starts to fix the problem.  I’d rather have ciphertext being sent across the network than plaintext.  Users just need to understand what the risks are and evaluate whether they are okay with those risks or not.

Fedora Security Team 90-Day Challenge to clean up vulnerabilities… an update

2015-05-29 Leave a comment

At the beginning of April, the Fedora Security Team (FST) started on a journey to close all critical and important CVEs in Fedora and EPEL that had originated in 2014 and before.  Now that we’re two-thirds the way through I figured it would be a good time to see what we’ve accomplished so far.

Of the 38 CVEs (37 important and 1 critical) we originally identified: 14 have been closed, 1 is currently on QA, and 23 remain open.  The 14 closed CVEs represent around a third of all the identified CVEs.  So, not bad but also not great; there is still work to be done.

If you want to help get some of these CVEs cleaned up here’s a list of the target packages.  We need to make sure that upstream has fixed the problem and that the packagers are pushing these fixes into the repos.

  • ytnef
  • mediatomb
  • rubygem-httparty
  • rubygem-extlib
  • rubygem-crack
  • nagios
  • libmicrohttpd
  • directfb
  • nagios-plugins
  • dcmtk
  • sahana
  • opensaml-java
  • s3ql
  • tomcat
  • openstack-keystone
  • phpMemcachedAdmin

I hope to come back to you at the end of the month with a report on how all of the CVEs were fixed and who helped fix them!

Fedora Security Team’s 90-day Challenge

2015-04-23 Leave a comment

Earlier this month the Fedora Security Team started a 90-day challenge to close all critical and important CVEs in Fedora that came out in 2014 and before.  These bugs include packages affected in both Fedora and EPEL repositories.  Since we started the process we’ve made some good progress.

Of the thirty-eight Important CVE bugs, six have been closed, three are on QA, and the rest are open.  The one critical bug, rubygems-activesupport in EPEL, still remains but maybe fixed as early as this week.

Want to help?  Please join us in helping make Fedora (and EPEL) and safer place and pitch in to help close these security bugs.

For discussion: Orphaned package in Fedora

2015-03-26 8 comments

The Fedora Security Team (FST) has uncovered an interesting problem.  Many packages in Fedora aren’t being actively maintained meaning they are unofficially orphaned.  This is likely not a problem since at least some of these packages will happily sit there and be well behaved.  The ones we worry about are the ones that pick up CVEs along the way, warning of unscrupulous behaviour.

The FST has been plugging away at trying to help maintainers update their packages when security flaws are known to exist.  So far we’ve almost hit the 250 bug level.  Unfortunately we forced a policy that still isn’t perfect.  What do you do with a package that is no longer is supported and has a known vulnerability in it?  Unless you can recruit someone to adopt the package the only responsible choice you have is to retire the package and remove it from the repositories.

This, of course, leads to other problems, specifically that someone has that package installed and they know not that the package is no longer supported nor do they know it contains a security vulnerability.  This morning, during the FST meeting, we discussed the problem a bit and I had an idea that I’ll share here in hopes of starting a discussion.

The Idea

Create a file containing all the packages that have been retired from a repository and perhaps a short reason for why this package has been retired.  Then have yum/dnf consume this information regularly and notify the user/admin when a package that is installed is added to this list.  This allows the system admin to become aware of the unsupported nature of the package and allows them to make a decision as to whether or not to keep the package on the system.

Okay, discuss…

Categories: Fedora Project, Security

A change in thinking…

2015-03-25 Leave a comment

When I entered the information security world in late 2001 I received training on communications technologies that included a significant interest in confidentiality.  Obviously the rest of the trifecta, integrity and availability, were also important but maintaining communications security was king.

Now, almost fifteen years later, I’m still focused on the trifecta with confidentiality coming out with a strong lead.  But my goals have changed.  While confidentiality is an important piece of the puzzle, for privacy and other reasons, I feel it should no longer be king with my work and writing.

Over the coming weeks I plan to focus on the availability of data.  And not just whether or not a file is on a server somewhere but diving into the heart of the availability problem.  File format standards, flexibility of the data to be used with accessibility tools, ability to translate the words into other languages to ease sharing, and the ability to move the information to other forms of media to improve access are all topics I want to cover.

I’m largely writing this as a reminder of ideas I want to research and discuss but I hope this gets other people thinking about their own works.  If you have a great idea don’t you want to make it easier for other people to consume your thoughts and be able to build on them?  Unfortunately the solution isn’t simple and I suspect much will be written over time about the topic.  Hopefully we’ll have a solution soon before that StarWriter file you have stored on a 5.25″ floppy drive is no longer readable.

Categories: Availability