Search

Subscribe

FEEDTROUGH: NSA Exploit of the Day

(TS//SI//REL) FEEDTROUGH is a persistence technique for two software implants, DNT's BANANAGLEE and CES's ZESTYLEAK used against Juniper Netscreen firewalls.

(TS//SI//REL) FEEDTROUGH can be used to persist two implants, ZESTYLEAK and/or BANANAGLEE across reboots and software upgrades on known and covered OS's for the following Netscreen firewalls, ns5xt, ns25, ns50, ns200, ns500 and ISG 1000. There is no direct communication to or from FEEDTROUGH, but if present, the BANANAGLEE implant can receive and transmit covert channel comms, and for certain platforms, BANANAGLEE can also update FEEDTROUGH. FEEDTROUGH however can only persist OS's included in its databases. Therefore this is best employed with known OS's and if a new OS comes out, then the customer would need to add this OS to the FEEDTROUGH database for that particular firewall.

(TS//SI//REL) FEEDTROUGH operates every time the particular Juniper firewall boots. The first hook takes it to the code which checks to see if the OS is in the database, if it is, then a chain of events ensures the installation of either one or both implants. Otherwise the firewall boots normally. If the OS is one modified by DNT, it is not recognized, which gives the customer freedom to field new software.

Status: (S//SI//REL) FEEDTROUGH has on the shelf solutions for all of the listed platforms. It has been deployed on many target platforms.

Page, with graphics, is here. General information about TAO and the catalog is here.

In the comments, feel free to discuss how the exploit works, how we might detect it, how it has probably been improved since the catalog entry in 2008, and so on.

Comments

Most of the TAO bios-attacks just strike me as "duh": If you want persistence across reboots and software updates, you hide in the BIOS/firmware. You do it right, you even intercept the firmware reflash so you can persist across a "firmware update".

What is needed is probably a "high/low" rootkit style test: An in-the-OS dump of the firmware and a "clip to the motherboard" dump of the firmware, basically a device that reads the FLASH directly by hooking onto the pins and reading the contents directly.

Difference? You got a BIOS rootkit.

(What actually surprises me is their emphasis on persistence, not just here but with the whole QUANTUMNATION suite: With such an ability to compromise systems with QUANTUM, so much of their workflow would work just fine with NO persistence, which makes detecting the attack much much harder)

They can all be coerced by the government to backdoor their products, and keep quiet about it. And they can't be scrutinized by as many people as open source things can, so more vulnerabilities remain... Closed source is security by obscurity, i.e. it is no security at all.

I'm with DB. That the box is a firewall makes it a no brainer: use one of the solutions based on BSD or Linux. You then have a chance of securing it or running it with protected firmware. OpenBSD and pfSense come to mind as they have straightforward instructions. OpenBSD, NetBSD and Linux based solutions also have the advantage that they're portable across old and new processor architectures. Adds an extra step where they have to guess what kind of box you have.

Lastly, the security enhancing research prototypes I've been posting work with Linux and BSD systems; MIPS and SPARC hardware. So, choosing such things might let you leverage cutting edge protection on top of whatever best practices you use.

An obvious way to watch is to having an OS confirm its BIOS ("Is this BIOS the same one I've seen before?"), but that mean you have to have a mechanism to both set the recognition and protect the means of authenticating.

Using a LiveCD-type OS would be a means of protecting the OS, but then you have an issue of handling legitimate updates to one or both. Using "real" read-only memory on the OS would mean that every copy becomes obsolete and has to be remade when you update the BIOS--you gotta toss the CD and create a new one just for that machine...or a trusted copy...

...and you're stuck at how much you can trust what the BIOS is saying. "Trust me, I'm the same version" can be helped with some cryptographic authentication, but anything that can be written can be rewritten.

Subverting BIOS, to me, has always been a logical step in the us vs them war. Trusted Computing just offloaded the work onto someone else, but you have to trust (no pun intended) that both sides of the equation would not work together to screw you over. Recent NSA revelations sure threw that one out.

I think the only way a company, like Juniper, can defeat this would be to re-architecture the way BIOS and OS software are handled at the hardware and boot level, and even then you have to "trust" that they both got it right and didn't intentionally subvert the process. (And there's that word again...)

Can they legally do this? Some time back, I think it took a law passed by Congress, to relieve the FBI of the responsibility of keeping the national crime database accurate and up to date. Essentially, they didn't want to be held accountable for any errors in the data that caused any type of problem for a U.S. citizen.

So, to simply change their purpose from "law enforcement" to "national security" seems to require some legislative initiative under which they are defined as a federal agency. Further, it seems to be in direct conflict with the agenda of the Department of Homeland Security, which makes "national security" their battleground or turf, so to speak. And where does that leave the NSA? Or the CIA for that matter? Instead of having these organizations cooperate with each other, they are into a battleground for the turf of others. Further, with NSA collecting so much data that could be used for "law enforcement", maybe the FBI just doesn't want to be saddled with making use of that data, so they kiss off law enforcement.

Interestingly enough, it appears that criminals can now ignore the FBI since they no longer perform law enforcement duties. So, who do we turn to for crimes committed across state lines? Probably nobody, which will make lots of shady businesses very happy that the FBI will no longer be on their tails. That means all sorts of unscrupulous activity, like ALL INTERNET FRAUD, will now go uninvestigated and unsolved...a tremendous opportunity for criminals. Anybody that sells across the Internet will no longer have to be worried about bad products, delivery, service, or criminal investigations with regard to fraudulent activity shoddy goods, or unscrupulous marketing. If you thought that online retailer was bad before...

There seems to be a new layer in the stack: Under what quality of political system, demonstrated thru the quality of legal system, is the software/ hardware/ service produced? If the political/ legal system is weak (ie not transparant, not respecting democratic norms) then nothing else matters - fail from security point of view.

So:
1) In what country can we find high quality law and high quality political system? Lets find it.
2) Only buy from providers/ etc who has their seat/ HQ in such a country.

Time for internet and the IT business to leave US - sorry but the US has blundered.

Mere speculation on my part,, but looking down the list of NSA TAOs reminded me of the badBIOS article, instead of an all-powerful single piece of malware, it seems more likely that Dragos Ruiu is being investigated, his systems regularly reinfected by state actors.

This article describes how an attacker can obtain, modify and install a modified version of Juniper ScreenOS which can run attacker supplied code which performs hidden operations or operations contrary to the configuration of any Juniper platform running ScreenOS.

...
Netscreens are manufactured by Juniper Inc and are all in one firewall,
VPN, router security appliance. They range in scale from SME to Datacentre
(NS5XP -- NS5000). Mos
"

@David or just don't "trust" them at all... no closed source OS, no closed source BIOS, no closed source Firmware, no closed source anywhere... make it all open source. Then every security professional in the whole wide world can check it and see how secure it really is. And every end-user should install their own copy of all the above too, in case of it being messed with in the mail.

When you get your first computer, where do you get the software to install on it? Order it in the mail? It's susceptible to the same tampering you're trying to prevent. Download it? How, when your first computer doesn't have software you trust? Etc.

Therein lies the first part of the problem--where do you start to trust. The software that you install, the hardware that you buy, the administrator that does the installation...all points where there comes a moment when you simply have to have faith.

On the other side of it are two competing players--one environmental, the other an opponent.

The opponent is easy to understand--agencies like the NSA. For good or ill, they are trying to circumvent any protection system. On their side is money, brains, time, and the fact the 99% of users don't really look at the source code, even if they have it available.

The environmental factor is the junction of economics and standardization--mass production with standardized components. It makes the NSA's job easier because if they can find one or more holes in any popular hardware/software product, their reach immediately extends to anyone who has that product.

This is the damage that the NSA has done--to the big "environmental" players. Trust in Juniper and others (Cisco, RSA, MS, etc) has been damaged in ways we've only begun to see. This undercuts the system, drives dollars to and fro, and leaves the little guys like you and me looking for alternatives.

Not my point, but @Bruce's: Change the environment, build in security from the ground up, vote with your wallet.

If they are after you, they'll probably get you, but make the overall environment more hostile and expensive. That way "they" go back to targeted attacks rather than broad sweep-em-ups.

There are cryptographically secure ways of downloading things and making sure they haven't been changed in transit. Every system that downloads software should use such things.

Yes, there is still a problem with most hardware. But there are open source hardware projects too, albeit only smaller hobbyist ones so far. It's something I hope grows though.

BIOSes and Firmware are not hardware. They are software, they should all become open source. No closed source can be trusted. Our "faith" should not be blind, especially in things that have been proven to be untrustworthy. Building in security from the ground up means building in openness from the ground up. Then we can "trust but verify" all the way from the top to the bottom.

Yes, there is still a problem with most hardware. But there are open source hardware projects too, albeit only smaller hobbyist ones so far. It's something I hope grows though.

Agree and agree. My only nuance to that is that it's easy to say and easy to advocate--even easy to follow for someone who is willing to get their hands dirty and pay attention.

But the world at large generally goes along the path of least resistance. You need a WIFI router, you run out to [favorite/easy store] and get one, because they are mass-produced, cheap, and accessible. Rolling your own (which I have done and occasionally still do) or comparing latest vulnerabilities is another thing entirely, and outside what most people are willing to do.

It's not that it's hard--more that we live in a black-box world, and the "faith" factor is pretty high if you start picking it apart. I like learning about this stuff, and I'm sure you do, too. But to the average consumer anywhere in the world, it's all magic--they just want the magic to be predictable and affordable.

That's where the problem lies.

Also wanted to add that I don't believe I've ever seen @Bruce explicitly say, "Vote with your wallet." I think it's a logical extension of what he does advocate, but that phrasing was my own. I try to be precise, and appreciate that in others, so my apologies for poor phrasing.

If the NSA isn't aware of this, then it's even more reason why they need to be shut down and many people fire -- they're f'ing clueless.

However, I think they know what they're doing -- they know only larger companies will use Juniper. Any defence of "for national security" is laughable and disgusting when you consider this.

Open source FTW. It isn't a 100% guarantee, but it's the best shot you've got. Open source gear is also less likely to hide nefarious traffic as well. It'a always a good idea to keep an eye on your equipment and see just where it's talking to. I do periodic sweeps on my networks, primarily to detect spyware and possible security breaches. The NSA/FBI/any other asshattery is also considered a security breach in my book.

“...BANANAGLEE across reboots and software upgrades on known and covered OS's for the following Netscreen firewalls, ns5xt, ns25, ns50, ns200, ns500 and ISG 1000…”

This seems to indicate in-depth knowledge of the both the firewall and the underlying OS throughout the development and debugging. It is doubtful the government could pull off these types of hacks without inside information from the builders of the firmware, OS and the firewall.

[Bruce S.]

“…feel free to discuss how the exploit works, how we might detect it, how it has probably been improved…”

Talk to Yan Ke, Ken Xie, Anderson Chen and the Juniper crew (that is Ken Xie who graduated from Tsinghua University in Beijing, China). They built, integrated it and debugged it. They know the system inside-out. They know the holes.

“NetScreen Technologies was founded by Yan Ke, Ken Xie, and Feng Deng. Ken Xie, Chief Technology Officer and co-founder was also the CEO until Robert Thomas joined in 1998…Ken Xie left NetScreen in 2000 to found Fortinet, a competing ASIC-based firewall company… In 2003 NetScreen hired Anson Chen as its vice president of research and development. Anson Chen, a 12 year veteran of Cisco Systems, Inc. and its former vice president and general manager of the Network Management... [and] lead engineering, research and development efforts for NetScreen's entire product line, including its firewall, IPSec virtual private network (VPN) and intrusion detection and prevention technologies. Chen also had functional management responsibility for NetScreen's secure access products… Yan Ke and Feng Deng stayed with Juniper after the acquisition but then left Juniper in 2005 and started Northern Light Venture Capital, a China concept venture capital firm focused on early and growth stage opportunities in... clean technologies, and life science industries… NetScreen Technologies was acquired by Juniper Networks for US$ 4 billion stock for stock in 2004.”

I agree. Open source appears to be the only solution – assuming it is audited.

We were sold a “security solution” only to find it insecure (in hindsight and after actual documentation was published). This seems like a classic “bait-and-switch” scam but on a global scale.

My assumption was the capital markets pooled funds for large ethical R&D projects. The profit motive would provide competition to boost huge global projects such a Cisco, Juniper, Apple and so on.

It looks like I was wrong. The down side is greed. The big corporations have individuals who will sell-out. Government has the big money to buy those individuals. The game is rigged. Trust must be restored at all levels.

@DB, Qoheleth and David

You have described the big problem. That is massive interdiction at all points by an adversary with colossal resources; compounded the “trust” abdication issue.

When both the hardware and software can be pawned you have witches brew in communications systems. On a granular level the BIOS must check the firmware/hardware and hook the OS. With both pawned the system is leaky sieve.

This is a multifaceted problem. As Bruce says it is also a political problem - which probably cannot be fixed by technical solutions alone (without capital resource equal to the adversary’s resources).

That’s not to say we cannot make it economically and technically difficult for the adversary - akin to an insurgent struggle against a larger adversary. The key is wide spread secure communications.

@ Xyz

“…article describes how an attacker can obtain, modify and install a modified version of Juniper ScreenOS which can run attacker supplied code…”

That just the code the NSA needs… oddly enough.

@ kashmarek

It looks like the FBI wants to wear the “National Security” badge as a catch-all, a mechanism to avoid critical parts of the Constitution, and a general “Get-out-of-jail-free” card.

The term “National Security” has become so grossly stretched it can justify any action. The term “National Security” must be narrowed and clearly defined.

BTW, I don't see much Macromedia corp mentioned with regard to NSA stories.

2. From docs looks like despite of sophistication, there are simply logistical limits to NSA spying on Americans. They would need hundreds and hundres of case officers to use that on mass scale. I would say, it is for mostly overseas targets. Which is fine with me.

3. Docs also confirm that Bill Gates whored himself out all along in exchange for helping him to monopolize OS market. That night come back to bite NSA' ass, as this scenario is relies on Windows market share among the targets, whereas Linux was left mostly without the coverage.

OpenSource as alternative? Where to start here? Do you trust the compiler's libraries? The compiler itself? The linker? Etc. It is trivial to include hidden code in libraries...

You would need to disassemble anything after building, and look at the result. But wait, could the Disassembler hide something, or the routine that reads the file for disassembly? Yes. Paranoia at the best, but valid thoughts.

I was thinking this over a bit more... and am really hoping someone, somewhere starts exploiting NSA back doors. I have a strong suspicion these back doors will probably make the United States even more vulnerable than if the NSA didn't exist, once some hackers working for unfriendly parties.

I'm also wondering how many critical life-safety and medical systems are infected with NSA back doors and the implications thereof. Does your pacemaker have an NSA kill-switch backdoor?

@Christian yes you do have a bit of a chicken-and-egg problem with compilers. However, you have to start somewhere, and the more eyes are on something the better it is. It should be as open as possible, not closed and secret.

The main advantage of open-source vs. the NSA is that you can easily customize it. Right now the NSA is taking advantage of the fact that its targets leak a lot of configuration info just by being off-the-shelf: either proprietary products, Windows, or well-known Linux distros.

The NSA's nightmare world:

A world in which everyone ran Linux (or substitute any other FOSS platform in the following)

Every Linux installation chose randomly from 2 or more independently coded alternatives for every built-in command, and every kernel module

The kernel and the more complex applications are built on-the-fly for every installation, a la Gentoo, and the build system randomly chooses between swappable independently coded internal modules when compiling

Instead of the current "packaged" desktop environments, all of the various desktop functionality would be mix-and-match, and the user would be actively encouraged to try out the various alternatives

Of course, this new world would also be a nightmare for software maintenance, since no one would be running anything exactly identical to anyone else --- all bug reports would have to expose sufficient information to enable debugging, so I suppose that there would be an automatic recompilation/reshuffle process (probably not for the desktop customization, however, except for the most paranoid users) run after every bug report. (I suppose that that reshuffling process might very well incidentally solve the bug for the end user automatically, though.)

If, somehow, attacks could be automatically detected/reported when directed against the "wrong" modules, it would, of course, be another order of magnitude more nightmarish for the NSA, since the only documented cost/risk analysis they seem to do is with respect to their exploits.

Sigh. You know what's disgusting? That people don't understand how BIOS actually works any more. Not at all.

First of all, if it was in BIOS, it would be show in standard BIOS forensics. Period. Either that or you're doing it wrong. There is no third option, and I would certainly know - I've DONE it. Anyone affected by it would know the second they pulled ANY misbehaving gear into a diag lab that something had tampered with it.

People need to stop spreading this outright false information about 'badBIOS' and such. Period. Just because paranoia is proved correct doesn't mean you're not completely and utterly wrong from a technical standpoint. You think you're right? Pull the suspect chip, do an SPI dump and send it to an expert to disassemble. (Provided binary updates are more frequently partials.)

FEEDTROUGH doesn't reside in the BIOS, end of story. Can you get covert channel comms of sufficient complexity to do the job in less than 512 BYTES of data? Oh, and it can't be in hardware without subverting the entire chain and multiple factories - these are devices built with many parts right off the shelf. Same for stealthing it in the CMOS parts themselves - you would have to subvert multiple factories at multiple suppliers. Nobody single-sources the flash.

And nobody competent enough to write something in 512 bytes is going to be stupid enough to put it in a place where it can be EASILY found. I can very, very easily find out if a BIOS' contents have been altered with $10 in hardware from eBay. Occam's Razor: if some random guy changing his BIOS logo can find it easily, then it's not going to be there. I mean seriously - that would be just the height of stupidity on the developer's part.
Plus, for stuff like Juniper, Cisco, etc, the BIOS is mostly what's termed generally as "non-reference" meaning they aren't just customizing AMI, Award, etc. Nevermind that it's non-UEFI and therefore true zero-portable - code cannot be re-used safely even between 'minor' hardware revisions.

Not to mention, every proper forensic analysis has found no evidence of the claimed 'badBIOS' and variants to date. That's because, hey guess what, it's not in the BIOS. See, the BIOS is like a piece of paper that you write on with pen. What's on there is what's on there. Put it down in another room away from the notebook it came from, and the letters haven't changed - they can't. You can't just magically erase any evidence of it, especially if it hasn't been toggled to write and is currently running and the malware can somehow detect physical access and the list goes on and on.

So I guess congratulations to all the people who have wasted hours doing forensics wrong or in the wrong place? I mean seriously; use your common freaking sense here. What are you going to do in 512 bytes? And why 512 bytes?

Because 512 bytes is total space for an MBR. And about the most guaranteed 'free' space you'll find, if you find any. And you're not going to put the payload in it. BTDT; it's uselessly small for complex malware - especially when you consider Flame was 20MB+ for a very small set of operations and devices. But if you want to set a series of registers in compromised devices nobody's had the good sense to look at, which are much harder to forensically inspect? Oh yes. And those devices also have more room and can lie dormant.
Oh, and the way the PC BIOS has to work permits you to set up an early stage MBR of 512 bytes that sets a bunch of registers and then does a 'go to next MBR' in less than 50 cycles at real-mode clock. And the only way you're going to catch that nasty is going cycle by cycle on actual hardware. Literally one cycle at a time.

And wouldn't you know it... most non-PCH USB controllers are burst reprogrammable and happen to be able to present as MBR capable. Just as a starting point. (It's definitely an entry point I would consider using if I had known quantity hardware using a common part.) Also remember that it has to begin prior to protected mode and persist past SMM; not a lot of possibilities.

Obviously a lot of gross oversimplification and leaving out a tremendous amount of details, but you get the general idea of it.

But really, it's a whole stack of Occam's Razor. Don't leave it in an area easily examined forensically; use the most common part for maximum coverage with minimum effort; use something with guaranteed variables (e.g. network stack present and not disabled, insensitive to external factors like link state, etc.); use the minimum size and effort to enable a wider range of payloads; and locate it in a device where any intervention or operation would have the least risk of exposing it or be unable to expose it including physical examination. CMOS has and always will fall on the wrong side of all of those.

Unfortunately, since this is related to some sensitive ongoing things, that's the extent of what I'm comfortable saying publicly or privately. In short: stop wasting everyone's time claiming it's the BIOS and pointing to the BIOS. It's not the damn BIOS; only for specific targeted platforms (as in FEEDTROUGH, but that is questionable for various reasons) is it BIOS related, and BIOS is being used as a generalization and lever.
Think you've got a sample? Start desoldering MACs (Ethernet for you younguns), third-party USB controllers, hard drive uCs, IPMI, and third-party SATA. Then dump onboard contents (oh how I do not envy people attempting that.) Don't waste time on SuperIO since any modern one loads from CMOS and can't act as MBR or loads from IPMI and will be in IPMI contents.

Unfortunately, GFL getting clean samples to compare against - I've been doing "bad things" with OROMs since 1997 and even I can't get a proof clean firmware for any of that. Proof clean means a sanitized build from the manufacturer - highly sensitive and proprietary. But those are the parts you should be looking at.

Will probably write up something on my blog again as to why TAO BIOS != 'badBIOS', never did, and never could - not ever. (Oh boy, sifting through 10,000+ spam or insane comments again.) It's as electrically impossible as 208VAC @ 30A from nothing but a 1.5V D cell. It is exceptionally depressing that so many supposedly 'technical' people haven't bothered to do enough very basic research to understand that simple fact.

@RootWyrm I have been working on device security since the 70's at all levels, IC design, semiconductor forensics (etching layers of an IC with nitric acid and watching the circuit operate via an Infra-Red microscope) and developing the firmware/software and I find your certainty amusing. Do you really believe you have seen everything?

For example, one device I built was an overlay die set up such that the data read by the CPU depended on the sequence of the addresses read. If you dump the ROM contents by serial reads you never see the overlay code.

I have also written small pieces of assembly code that perform a second hidden function if you enter it in the middle of a multibyte op code.

I have hand coded firmware patches in the field under the constraint that the bits in the ROM could only be changed from 1 to 0 and not vice versa and learned to squeeze several uses out of each byte.

Yes, please join the debate, your experience is welcome but please believe that you might also learn something. In this business we never stop learning, that's why it's such fun.

@Bob S Did you ever think they might be doing both at the same time? When a company is told that if they cooperate they get a free security audit, will be informed of the worst security vulnerabilities immediately and told about the others after a period of time during which the government can butt fuck the Chinese what do you think they are going to do?

There is absolutely no economic incentive for advanced software/hardware vulnerability discovery unless it can be used for crime or national security goals. At least in the latter there is at least some form of policy balance.

The main idea with them is that a target might be running numerous accounts off a single computer. The analyst wishes to expand an initial target tag (selector) to find a larger set of selectors (other identities used by the target, associates, favorite websites etc.)

Contact-chaining (2-3 hops) via querying the MARINA megabase of internet activity (DNI) is the whole focus of the Booz Allen instructional tutorial under discussion here. The trick is to keep it focused on the individual initially targeted and not wander off into his social network (that's a different tutorial).

Here the yahooBcookie comes into play as the index field in relational database language. One and only one yahooBcookie tag is issued per computing device. Thus all the various identities a target might take on in the course of internet usage on a given computer can be tied back to a fixed unique yahooBcookie.

If many people use the same computer -- think of a hotel lobby or public library -- this isn't going to be effective. If the user regularly clears out cookies -- the yahooB is not persistent like the Google_PrefID -- they'll not have a yahooBcookie until they make use again of a yahoo service.

However the Yahoo demographic largely consists of bottom-feeders, internet illiterates who take few if any security precautions and never delete their yahooBcookies.

Slide 17 (Spiegel online 9):
-- for yahoo email searches, now look at Machine IDs for recent yahooBcookies
-- yahooBcookies are unique to each computer and can hold alternative yahoo emails being logged into from that same computer
-- here the user had received 29 messages and logged in 22 times
-- here 18 Machine IDs were found and 7 shown
-- result here was two new selectors, a gmail from before and a yahooBcookie
-- the recent date for an oft-used address is most likely to give a stable selector, the date here is 05 Dec 2011
-- here 3 yahooBcookies were seen but only the most recent one was kept
-- other things seen in Machine IDs for web: yahoo voice 2.0, net_http_transaction_mpl_manager0.1, mozilla 4.0 (compatible; mse 5.5), mozilla 4.0 (compatible; mse 8.0; windowsnt),
-- these other things are not used further unlike the new yahooBcookie which uniquely identifies target computer until cookies are manually cleared

Slide 20 (Spiegel online 12):
-- the gmail account Marina profile yields 16 Equivalent IDs of which 13 are shown
-- 7 of these are display names, 5 are alt IDs, and 1 is registered with; of these only the alt ID at facebook provides another selector
-- often yahoo, hotmail, yahooBcookie provide opportunities for iterated selector enrichment but not in this example

RonK • January 7, 2014 12:35 AM
The kernel and the more complex applications are built on-the-fly for every installation, a la Gentoo,

I'm using gentoo for my linux box. I can only recommend gentoo. The problem is that you must run emerge -uD world very often, around once in a week or so, otherwise, the system easily gets problems. When updating an old gentoo installation, e.g. a one year old system, its often better to do a complete re-install, since there are so many changes, and incompatibilities with previous versions.

For servers, gentoo is therefore problematic. You might thing that a server could run emerge regularly, but you have also to modify config files, and the ordinary admin does not have time to edit many config files once in a week.

But gentoo runs very fast. Much faster than other distributions. I will tell the gentoo forum, that gentoo is mentioned as a security measure against NSA. They will certainly like that.

I've used Gentoo for servers before. It's not that bad, you really SHOULD be running updates fairly often anyway, if you truly want to be as secure as possible. Use a staging machine too if you want to make sure the latest updates won't mess things up (it can easily be a virtual machine). If you can't be bothered to run updates often, don't use Gentoo is my recommendation.

I'm another Gentoo user, happy until a little over a month ago with the awkward systemd rollout. I will agree with everything you've said, and that's good as far as it goes.

Short version - I believe systemd is a security disaster waiting to happen, for a few very simple reasons, none of which have anything to do with the code quality.

A little over a month back Gentoo rolled out systemd without warning, without news items, etc. Nor is Gentoo alone in that - many, if not most distributions are either in the midst of systemd rollout or contemplating doing so.

Point 1 - It appears that systemd is on its way to becoming a monoculture in Linux. Monocultures are always dangerous, from a security point of view. Attack one, attack them all.

Point 2 - Systemd is relatively new. We have no idea what its security is like, because there hasn't been enough time. No code is perfect, or at least no code that performs a real function. Given time and effort, security problems will be found with systemd.

Point 3 - Systemd is absorbing functions from other packages. In addition to acting as an init system it handles device management, (udev) daemon management, (perhaps the two least questionable add-ons) logging, (in binary format, no less) user session initiation. I believe one or two more functions have been recently absorbed. It's expressly counter to the old Unix Philosophy of "do one thing and do it well."

Point 4 - For all of the absorbing functions, systemd is still one package. If it were multiple packages, a better clarity of interface between the many functions might be more required, and clarity of interface is generally a good thing. As a secondary concern, one package has a single attack surface. It might be better or worse than interactions between multiple versions of multiple subpackages, but it is certainly a simpler attack surface.

Side note - There are those who believe that the diversity of the Linux ecosystem is really damaging fragmentation, and is what is holding it back in terms of market share. I get the impression (There is a mailing list note supporting this, which I can't find at the moment.) that the systemd team is trying to force a systemd monoculture on Linux, presumably as a way to improve market share. That of course discounts the security advantages of diversity.