Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Door and Corners

DZone's Guide to

Door and Corners

By now, you've all heard about the need to patch systems as updates or newer versions are made available. A DZone Zone Leader discusses why this continues to be an issue.

· Security Zone
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

Once again, we have an old, this time deprecated, service exposing a significant vulnerability. This is a common pattern - a bit over a year ago, the Google Zero project found a group of vulnerabilities associated with windows font handling. This time, Patrick Wardle at Synack outlined how an insecure, deprecated installation service available on MacOS can be abused to provide root access.

The details of the ways you go about compromising these services aren't important, really, to most of you. You're not writing malware, your systems are all patched, so life is good, right? But really, the point isn't the exact instances of these kinds of compromises. It's the pattern of compromise, and how we all contribute to it day-to-day.

The essence of this trap is a refusal to remove deprecated, older functionality, or to stop using old services. This is surprisingly common, and we all contribute to it.

How? Let's look at two different perspectives.

First, operating system designers are loath to remove features, even if they're old and hardly used. They know that hardly used is not the same as unused, and they don't want to turn off that one feature that some company depends on. Not only do they not want to deal with the press, they just don't want to make life difficult for the engineers in that company. If they turn off that feature, whatever it is, then that company will need to rush to work around the just-removed service. And they don't want to put folks in that position. That's understandable. It also takes time to remove a service, and test to ensure the system works correctly with the service removed. They'd like to avoid this too, for the same reasons app developers do.

How about developers then? Well, which would you rather do, work on a new feature that everybody's going to notice? One that'll get you promoted, or maybe get you a raise? Or work on porting code from some old service that works just fine to a new one that does the same thing? Will you get a raise or promotion for that? Not likely.

So this puts us where we are today. Removing old services and any dependencies on them are heavily counter-incentivized. There's just too much downside for anybody to want to spend any time thinking about it or working on it. But this is exactly where many exploits are found today.

At some point though, we all need to take responsibility for what we create. As engineers, as creators, we need to do the right thing, even if it's not the best thing (for us, at least). Make the effort to keep your code modern, keep it hardened, and keep your attack surfaces small.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
vulnerabilities ,security ,cybersecurity

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}