Archive

Category Archives for "Security"

Systemd is bad parsing and should feel bad

Systemd has a remotely exploitable bug in it's DHCPv6 client. That means anybody on the local network can send you a packet and take control of your computer. The flaw is a typical buffer-overflow. Several news stories have pointed out that this client was written from scratch, as if that were the moral failing, instead of reusing existing code. That's not the problem.

The problem is that it was written from scratch without taking advantage of the lessons of the past. It makes the same mistakes all over again.
In the late 1990s and early 2000s, we learned that parsing input is a problem. The traditional ad hoc approach you were taught in school is wrong. It's wrong from an abstract theoretical point of view. It's wrong from the practical point of view, error prone and leading to spaghetti code.

The first thing you need to unlearn is byte-swapping. I know that this was some sort epiphany you had when you learned network programming but byte-swapping is wrong. If you find yourself using a macro to swap bytes, like the be16toh() macro used in this code, then you are doing it wrong.

But, you say, the network byte-order is big-endian, Continue reading

Join Us: Immerse Yourself in Networking and Security at VMworld Europe

We are looking forward to a fantastic show at VMworld 2018 Europe. We have a ton of great content on networking and security to share with you including breakouts, labs, activities, and parties! You’ll have prime opportunities to learn about the Virtual Cloud Network, the latest on the NSX product portfolio, and network with your peers and VMware experts.

To get you started for a packed week of learning and fun, we highly recommend attending our two showcase keynotes:

First, at the NSX Keynote: Building the Network of the Future with the Virtual Cloud Network (Tuesday, 06 November, 14:00 – 15:00), you’ll hear Tom Gillis, the new GM of NSBU lead discussions on:

  • VMware’s vision for networking with the Virtual Cloud Network
  • The latest and greatest innovations across the NSX product portfolio
  • Joint solutions we are bringing to the cloud with IBM
  • A special conversation with key customers about how they are using NSX today
  • And, demonstrations showing the entire product portfolio in action including NSX Data Center, NSX Cloud, NSX SD-WAN by VeloCloud, and AppDefense

 

Next, at the Security Keynote: Transforming Security in a Cloud and Mobile World, (Wednesday, 07 November, 14:00 – 15:00), Tom Corn, Continue reading

NSX at VMworld 2018 Europe – The Technical Session Guide

Hola! VMworld 2018 Europe is around the corner and we look forward to connecting with our VMware NSX community in Barcelona.  Before we go into session recommendations, let us give you a recap on what we have been up to since VMworld US.

Since VMworld US in August 2018, we have announced general availability for NSX-T Data Center 2.3. NSX-T Data Center 2.3 extends NSX platform support to Bare Metal servers, enhances multi-cloud control in AWS & Azure, advances security with N/S service insertion, and has many more enhancements.

Our friends from vSphere have also released vSphere 6.7 Update 1 which gives NSX-T N-VDS visualization in the vCenter now.

For automation fans, we have a Concourse CI pipeline which automates the NSX-T install. This pipeline can be used to stand up entire NSX-T environments on vSphere clusters by filing a simple parameter file.

NSX-T Concourse Pipeline information

Now, let’s talk about our VMworld Europe line-up. As usual, we have great technical deep-dives, deployment stories, and hands-on labs for you. For the technical enthusiasts who are interested in deep-dives and deployment strategies, here are a set of “geek” sessions to choose Continue reading

Masscan as a lesson in TCP/IP

When learning TCP/IP it may be helpful to look at the masscan port scanning program, because it contains its own network stack. This concept, "contains its own network stack", is so unusual that it'll help resolve some confusion you might have about networking. It'll help challenge some (incorrect) assumptions you may have developed about how networks work.
For example, here is a screenshot of running masscan to scan a single target from my laptop computer. My machine has an IP address of 10.255.28.209, but masscan runs with an address of 10.255.28.250. This works fine, with the program contacting the target computer and downloading information -- even though it has the 'wrong' IP address. That's because it isn't using the network stack of the notebook computer, and hence, not using the notebook's IP address. Instead, it has its own network stack and its own IP address.

At this point, it might be useful to describe what masscan is doing here. It's a "port scanner", a tool that connects to many computers and many ports to figure out which ones are open. In some cases, it can probe further: once it connects to Continue reading

Some notes for journalists about cybersecurity

The recent Bloomberg article about Chinese hacking motherboards is a great opportunity to talk about problems with journalism.

Journalism is about telling the truth, not a close approximation of the truth,  but the true truth. They don't do a good job at this in cybersecurity.

Take, for example, a recent incident where the Associated Press fired a reporter for photoshopping his shadow out of a photo. The AP took a scorched-earth approach, not simply firing the photographer, but removing all his photographs from their library.

That's because there is a difference between truth and near truth.

Now consider Bloomberg's story, such as a photograph of a tiny chip. Is that a photograph of the actual chip the Chinese inserted into the motherboard? Or is it another chip, representing the size of the real chip? Is it truth or near truth?

Or consider the technical details in Bloomberg's story. They are garbled, as this discussion shows. Something like what Bloomberg describes is certainly plausible, something exactly what Bloomberg describes is impossible. Again there is the question of truth vs. near truth.

There are other near truths involved. For example, we know that supply chains often replace high-quality expensive components with cheaper, Continue reading

What Makes a Security Company?

When you think of a “security” company, what comes to mind? Is it a software house making leaps in technology to save us from DDoS attacks or malicious actors? Maybe it’s a company that makes firewalls or intrusion detection systems that stand guard to keep the bad people out of places they aren’t supposed to be. Or maybe it’s something else entirely.

Tradition Since Twenty Minutes Ago

What comes to mind when you think of a traditional security company? What kinds of technology do they make? Maybe it’s a firewall. Maybe it’s an anti-virus program. Or maybe it’s something else that you’ve never thought of.

Is a lock company like Schlage a security company? Perhaps they aren’t a “traditional” IT security company but you can guarantee that you’ve seen their products protecting data centers and IDF closets. What about a Halon system manufacturer? They may not be a first thought for security, but you can believe that a fire in your data center is going cause security issues. Also, I remember that I learned more about Halon and wet/dry pipe fire sprinkler systems from my CISSP study than anywhere else.

The problem with classifying security companies as “traditional” or “non-traditional” Continue reading

TCP/IP, Sockets, and SIGPIPE

There is a spectre haunting the Internet -- the spectre of SIGPIPE errors. It's a bug in the original design of Unix networking from 1981 that is perpetuated by college textbooks, which teach students to ignore it. As a consequence, sometimes software unexpectedly crashes. This is particularly acute on industrial and medical networks, where security professionals can't run port/security scans for fear of crashing critical devices.

An example of why this bug persists is the well-known college textbook "Unix Network Programming" by Richard Stevens. In section 5.13, he correctly describes the problem.
When a process writes to a socket that has received an RST, the SIGPIPE signal is sent to the process. The default action of this signal is to terminate the process, so the process must catch the signal to avoid being involuntarily terminated.
This description is accurate. The "Sockets" network APIs was based on the "pipes" interprocess communication when TCP/IP was first added to the Unix operating system back in 1981. This made it straightforward and comprehensible to the programmers at the time. This SIGPIPE behavior made sense when piping the output of one program to another program on the command-line, as is typical under Unix: Continue reading
1 … 72 73 74 75 76 … 177