A high level overview #Meltdown

Leaking data from the core of the operating system to an unprivileged program

The system running on your computer consists of two parts, the operating system (Windows, Linux, Android, MacOS) and the programs you run (Internet Explorer, Firefox, Photoshop, Warcraft, Chrome, Safari, Steam)

Although it’s not easy for the end user to tell the difference apart from many of the built in applications from the core of the operating system but if you interact with it IS an application and this is known as USER SPACE.

That underlying core, known as THE KERNEL, acts as a broker between USER SPACE (the applications) and the actual hardware of the computer. That’s the DISK, NETWORK, WiFi, SCREEN, KEYBOARD, MOUSE etc

In order to keep the KERNEL separate from USER SPACE computer processors (this is the CPU and is a big piece of electronics in the heart of your computer) are designed to have several levels of operation called RINGs. The most important of these are RING0 which is where the KERNEL is supposed to run and RING3 which is where USER SPACE is supposed to run.

In order to improve the speed of your home computer the manufactures have used various methods of trying to predict what program code is going to run next. Unfortunately the techniques used have flaws and it is possible for someone to write a simple program which runs in USER SPACE, this can even run in your web browser, which would allow the owner of a website to access passwords, cryptographic keys (PGP etc), bitcoin, your thumb print or face ID, your bank authentication, etc in the KERNEL.

The software updates being issued by Microsoft, Apple, Linux, etc are effectively working around a fundamental problem with the design of the electronics in computer chips and until the manufacturers resolve these they will exist for years  if not decades to come.

Advertisements

Tech fails in action – Rsync misuse

Take a scenario of having to synchronise several webservers with identical content, rsync would seem a reasonable choice.It just comes down to how you implement it.

What you don’t do is run rsync pull via cron, with two similar jobs, both writing to the same log file (overwring the same log file whilst dutifully sending stderr there as well), running under a normal user whilst trying to use the root only -o option.

Other things you don’t do is to modify a production web server and the let the replicas PULL the configuration to them using the aforementioned rsync/crontab. This needs a Picard facepalm!

“Well it used to work before!”, was that before you weren’t allowed to run it as root maybe? Guess the answer. You ran it as ROOT??!!! So any compromise would have been replicated as root and you’d have no log files to trace what might have been.

“So what’s the solution?” Well getting a proper deployment system in place that pushes out configurations from a seperate deployment server.

To spell it out:

  • Legacy use of root needs to be weeded out and exterminated
  • Configuration servers should ALLWAYS exist outside of end user access
  • Always PUSH configuration from the configuration server
  • All logs go to Syslog, never ever write your own
  • Any requirements to vary the deployment from this get rejected