Time to Git ZFS | TechSNAP 103 | Jupiter Broadcasting

Is your bucket exposed to the public? A security researcher has recently discovered many S3 buckets are publicly available, we’ll share the details.

Plus how the KDE project avoided a git disaster, the root problem with Java, a big batch of your questions, and much much more!

Thanks to:

GoDaddy.com

Use our code hostdeal4 to score economy hosting for $1 a month, for one year.

35% off your ENTIRE order just use our code go35off4 until the end of the month!

Ting.com

Visit techsnap.ting.com to save $25 off your device or service credits.

Direct Download:

RSS Feeds:

Support the Show:

Purchase anything at Amazon.com
Purchase anything at Think Geek using this link
Purchase anything at Newegg using this link
Contribute directly on our donation page or check out our advertising options and reach millions of amazing people!
Grab our Chrome Extension and auto-tag your shopping session for us!

<a href="https://jblive.wufoo.com/forms/s7x2p7/" title="Sign up for the Jupiter Signal!">Fill out my Wufoo form!</a>

Show Notes:

Get TechSNAP on your Android:

Browser Affiliate Extension:

Jupiter Broadcasting Affiliate Extensions for Chrome and Firefox

Amazon S3 buckets unknowingly exposed?

Security researcher Digininja was watching an old Hak5 episode about Amazon S3 and decided to give the free trial from Amazon a try
All S3 buckets are accessed as: bucketname.s3-region.amazonaws.com
An S3 bucket can be marked as Public or Private
If you access the root of a Public bucket, you are given a list of the files inside that bucket
Public S3 buckets can contain files that are marked as either Public, or Private
Attempting to access a file marked private without an access key will return a HTTP 403 error
While experimenting, he found that if you try to access a bucket that is assigned to a different region, amazon gives you a helpful redirect message
Based on this, Digininja decided to try a wordlist against the Amazon S3 subdomain, and see what he could find in other peoples’ buckets
Digininja was surprised to find that many buckets were marked public, rather than private
While scraping through the results, he found a number of documents that should have been marked private but were not, including a Ministry of Defence training requisition form (containing personal information including SSN), a spreadsheet containing the accounts of a company, and many personal photos and videos
It seems a lot of people are unknowingly making the contents of the S3 buckets public
A number of people also appear to be trying to use S3 as a CDN, using it to host the images for their website (S3 is not a CDN, it can be rather slow, Amazon has a separate service to serve the contents of S3 via a CDN, called CloudFront)
Researcher’s Blog Post
Researcher’s Findings Post

The narrowly avoided Great KDE Disaster of 2013

On March 22nd, the server that hosts git.kde.org was shut down for security updates, when it restarted there was evidence of file system corruption
The original cause of the problem was not determined
The real problem came, when the anongit mirrors of the 1500 KDE repositories mirrored the corrupt data, and there were no uncorrupt mirrors left
The problem stems from the fact that in the replication strategy, git.kde.org was always considered to be correct
The system they had in placed relied on the ability to sync an anongit mirror back upstream if there was a problem with the master
It seems that git –mirror just copies data from the master, without the usual verification and safety measures that happen in git clone
Luckily, KDE was in the process of replacing the projects.kde.org server, and it happened to have a mirror of the git repo from before the corruption, and they were able to restore git.kde.org from that
The article goes on to discuss a number of the steps they are taking to make their system more robust in the future
Update with more information to responses to common comments
The update addresses the sysops 101 adage “mirrors are not backups”
It talks about the problems they have with traditional backup systems
tar: how do you take a tar archive of a live system? keeping .tar files going back 30+ days would take too much space (or cost to much to use S3 etc)
rsync: same problem with a live system and rsync creates a mirror, which is not a backup
Any answer? ZFS
ZFS RAID Z, and ZFS snapshots are STILL not a backup
But a ZFS snapshot can allow you to take a tar archive of a consistent version of the repo (no files will change with the tar is being made, since snapshots are read only
Or better yet, you could store the actual ZFS snapshots (via ZFS send), so that you are basically getting ‘incremental’ backups, only the changed blocks are stored in each snapshot (requires that you keep and initial full snapshot and all incremental snapshots since then). Managing this can be difficult
Backup software such as Bacula, running off the snapshots, would be the best solution

The root of the Java problem

According to research by Websense, 93.77% of all installs of Java that were surveyed are vulnerable to at least one known exploit
75% of devices run a version that is at least 6 months old, 50% more than 2 years old
79% of devices are using some version of Java 6, which has now reached its End-Of-Live