One of the most important concepts is how scope binds to “this”.
First announced almost a month ago, Shellshock continues to endanger un-patched web servers and Linux devices. So what is it? How can you tell if you’re vulnerable? And how can it be addressed?
What Is Shellshock?
Shellshock is a vulnerability in the
bash software program. Bash is a shell, installed to Linux and other operating systems in the Unix family. A shell is a software component that is deeply integrated into the operating system, which is what makes this vulnerability so insidious.
The Shellshock vulnerability is a bug in the parser. It was first introduced more than 20 years ago when a feature to allow exporting functions was added. The danger is that an attacker who could control the content of an environment variable could potentially execute arbitrary code on a vulnerable system. Remote code execution (RCE) vulnerabilities (also called “arbitrary code execution” vulnerabilities) are among the most dangerous. Paired with privilege escalation vulnerabilities or poor security practices (e.g. allowing web servers to run as privileged users), unaddressed arbitrary code execution vulnerabilities can lead to the complete takeover of vulnerable systems. Read more on Shellshock – CVEs, Patches, Updates, & Other Resources…
Google Protocol Buffers have become a very popular serialization mechanism for simple to complex/variant data structures. Due to the variation of message formats in a given protocol, the presence and/or lack of fields on an ad-hoc basis makes implementation in the C language somewhat of a challenge.
Three Protocol Buffers Libraries for C
Thanks to the open-source world, a couple of valid options exist, but choosing the right one depends on the complexity of the protocol and memory/performance requirements.
Google Protocol Buffers for C++
The obvious first choice may seem to go right to the source. Google’s Protocol Buffer Compiler supports the generation of a C++ protocol implementation from a .proto specification. Though you are developing in C, and your complier supports C++, you could use the C++ API directly from C, or at least create a C wrapper for the target protocol.
- Pros: Formally supported by Google, bleeding edge
- Cons: Well, it’s C++ and does lots of dynamic memory allocation
Read more on Google Protocol Buffers Libraries for C…
Also posted in C & C++ Tagged buffers, c
Over the last few months, I’ve had the opportunity to do a lot of work with DropWizard, an awesome Java web framework for developing RESTful web services.
I was recently prototyping a small application, and I wanted to serve static files directly from DropWizard. While this isn’t what DropWizard is primarily designed to do, I didn’t want to go through the process of setting up another web server just to serve static assets for a prototype. While DropWizard has some out-of-the-box support for serving static assets, I found the documentation surrounding it to be incomplete and confusing. It actually took me a couple hours of debugging to figure out how to do exactly what I wanted, So I thought I would document what I learned here.
/api. The limited documentation around serving assets in DropWizard suggest that setting up an AssetsBundle for
/ and changing the application context path in your config file should be enough to achieve this, but that did not work for me. I had to do the following steps: Read more on Serving Static Assets with DropWizard…
Also posted in Java, Web Apps Tagged java
While working on a library for property-based testing in C, I discovered a trick that can be used to make significantly nicer library interfaces in C99: “designated initializers”. As of C99, struct literals can have their fields set by name, in any order. The C99 standard explicitly updated the behavior for how fields in struct literals are handled:
6.7.8 point 21:
“If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.” (emphasis mine)
Since memory with static storage duration is already initialized to zero, this means that in C99 we can finally depend on stack-allocated structs’ fields being set to zero, rather than garbage data from previous stack frames. This is a huge improvement! If pointers to structs are used as arguments for function calls, it also gives C99 a portable way of using optional and keyword arguments. Read more on Nicer C99 APIs with Designated Initializers…
$routeProvider doesn’t come with the functionality to include a resolve in every single route on an application. But universal resolves can be added in using
angular.extend(), an angular method that copies one object into another.
A quick refresher on resolves in Angular routes: a resolve is a dependency that should be injected into the controller for a route. The main difference between using a resolve and just requiring the dependency in the controller is that promises in resolves are completed before Angular renders the controller. If there are any errors in completing the promise, the
$routeChangeError event triggers. Resolves take the complexity of completing a promise and checking for errors out of the controller itself. (You can read more on $routeProvider and resolves in the Angular docs.)
Read more on AngularJS: Adding One Resolve to All Routes…
We are currently working on a product that utilizes a long-range and low-bandwidth network. Moreover, the devices that are being communicated with are severely limited with regard to memory availability and CPU cycles. Given these constraints, it’s important that the network and devices are not overwhelmed with traffic.
Recently, we encountered a acute problem where the network and devices could easily be overwhelmed if they are powered on and join the network at approximately the same time.
When the devices join they communicate with a server, informing it that it has just joined and that it needs to be configured (name, time, etc.). It will continue to send these configuration requests at a steady rate until it receives all of the necessary configuration information. The problem is that the server would gladly respond to every request, even if the information it is sending is duplicated.
We had to make sure that duplicate messages were dropped within a certain time period. Read more on Simple Flow Control Made Easy…
Also posted in Java Tagged java
Scott recently posted about the theft property-based testing library in C. Theft is very similar to Haskell’s QuickCheck. Theft tends to have a little less magic than Quick Check for generating random input and for failure case reduction. Theft makes them more manual, but also gives you better control of how they work. The theft ruby gem is a direct port to allow the same kind of testing in Ruby. Let’s take a look at the value in property-based testing and walk through a contrived example in Ruby.
Testing complicated algorithms can be, well, complicated. Typically, a developer will try to reason about their code and come up with a representative set of test cases to exercise the normal flow of the algorithm as well as all of the edge cases. This approach can leave holes in test coverage and brittle tests to maintain. That leads us to property-based testing. Basically, generate valid, randomly generated input and validate that a particular property is true.
Scott’s post does a good job of showing a real world example on the heatshrink compression library. I’ll use a contrived example to show how the theft gem can be used in Ruby. Read more on QuickCheck in Ruby…
As a Professional Problem Solver, much of my work deals with installing, configuring, and managing the Operating System layer of an application stack.
Managing the OS layer has been the work of System Administrators for many years. With the advent of virtualization, it became relatively easy to create and destroy virtual machines. With the “cloud” many of us no longer even own physical servers. With DevOps tools and configuration management, we’ve created abstractions for configuration and automated provisioning.
The operating systems have remained relatively the same. When we’re not using a PaaS like Heroku, our application servers are often full Linux VMs. Even with containerization tools like Docker, the underlying OS is fundamentally the same. The advent of virtualization brought many changes, but we still haven’t seen the full impact of this paradigm shift. Read more on Re-imagining Operating Systems: Xen, Unikernels, and the Library OS…