Shellshock Vulnerability – Bash bug

Just recently (24 September 2014) the Shellshock bug has been discovered in the Unix Bash shell which is a wide spread used shell. This is also a known bug for OS/X based systems. Especially servers reachable in the Internet could be compromised quite easily.  According to various statistics, 50% of the Internet is driven by Unix flavored systems and almost all ports like HTTP i.e. Meaning even if you do not allow access via SSH or Telnet to this server it could be compromised via HTTP and the executable interpreter underneath.

The bugs cause Bash to unintentionally execute commands when they are stored in specially crafted environment variables and compared to the SQL Slammer in 2003 (which brought the Internet down for 12 minutes) could be worse.

Robert Graham (at errata security) who has discovered the bug wrote a little test script to demonstrate the bug which convinces machines to execute the ping command.

What does the ShellShock bug could do?

An infected host (probably a web server) scans for it’s next targets (as many as he can reach) and induces them to download the exploit code and those in turn start scanning and exploiting. This could be used for a DOS (Denial Of Service) download malware or whatever the author of that script intends to do.

How can I test if my Bash shell is vulnerable or not?

You can run this simple command below which will tell you if your Bash in vulnerable or not:

env X="() { :;}; echo busted" bash -c "echo stuff"

Result: busted stuff = Bash welcomes the bug
Result: stuff = safe (for now?)

Are there patches available?

Almost all Unix flavors have a patch available which can be updated via yum, apt-get or your choice of package manager.


StorNext cvfsck free space fragmentation


Many StorNext users have a handful of tools that come with the default StorNext installation, basic or full blown with interface.

One of those tools which can assist in troubleshooting is cvfsck. The most common use of cvfsck is to verify the file system itself. It’s a simple and powerful command line tool if you use it for the right reasons.


Checking the health of the file system can be done when the file system if active but not really recommended as the journal is updated frequently. It’s basically a sanity check which may lead you to the action to take the file system offline. Continue reading

Short-Sizing StorNext (cvfs) LUNs


Every now and then you may have seen it or never have … lucky you. Under certain circumstances you may face the problem that you have configured your RAID with the same LUN size or even have used the wizard of the RAID vendor and StorNext (and other tools) will show you a different size on the LUNs in the OS.


As a starting point, let’s assume our configured RAID provides 4 LUNs to the system. Two of those LUNs have a sector size of 9065074317 and two LUNs have a sector size of 9065074333. This can be seen in the output of /usr/bin/cvfs/cvlabel -l as follows: Continue reading

Never Mix Up Throughput or IOPS with Stream Performance

What to Know and What to Ask When You Shop for Storage at NAB or

How to Evaluate Different Storage Solutions for Post,  Where Real-Time Access Is Crucial


The most important mistake to avoid when evaluating a SAN (or NAS) storage solution is also the most common one: confusing throughput or IOPS with stream performance. Throughput or high IOPS will not provide you with the performance you need in a workflow with real-time access requirements.

And this is where it becomes tricky. Unfortunately not all storage vendors possess the expertise or experience to really understand the difference between the requirements of their standard industrial customers and their customers in the M&E or post-production sector. While industrial customers consider a storage setup with high throughput and IOPS to be high performance, customers in M&E need high (real-time) streaming performance. Bandwidth and IOPS are secondary, if not entirely irrelevant.  Post-production applications working with sequence-based raw (single frame) material write to and read from the storage sequentially, as opposed to unstructured IT environments where data is read and written randomly.

A pretty common and recurring situation when it comes to buying storage could look like this. A customer expects to have eight attached clients in total, six of which need real-time read/play in 2K raw, while two clients will require 4K raw access. Most customers do the math this way: 2 clients x 4K = 2400MB/s   +   6 clients x 2K = 1800MB/s; therefore a total throughput of 4200MB/s is required.

Since all storage vendors know what their products can do in regard to IOPS or random throughput, a vendor may tell the customer that they need, for example, two RAIDs, each providing 2500MB/s. Combined, that will provide the requested 4200MB/s, plus 800MB/s of overhead. For a standard IT-based environment, this calculation might be correct, and the SAN would probably be perfectly suitable. But when it comes to sequential and concurrent data access by more than one client at a time, the entire setup becomes a whole different beast. With a setup like this, the post-production facility will realize a couple of weeks after the SAN has been deployed that the performance is far below the eight concurrent streams they actually needed.

What went wrong? Our example customer XYZ’s requirements have not been accounted for, or – even worse – were not understood in full. To explain this in a pictographic example, customer XYZ needed a setup that was able to play two songs from a record at the same time – and vendor ZYX provided one turntable record player. Now the customer has to lift the arm of the record player (seeking) and move it to the new position on the record (latency), then lift the arm again to return it to the original position (seeking and latency) and start from the beginning. Every time the arm is lifted, there will be no music playing, no matter how fast the arm is moved.


Read full article at


  • " “Hello and welcome to my personal blog.

    In 20+ years working in diversified IT environments, I’ve gathered some wisdom that I’m happy to pass on and share some (hopefully) helpful and interesting tips and tricks around SAN/NAS solutions. "

    Roger L Beck