Debian Working on Reproducible Builds To Make Binaries Trustable

An anonymous reader writes: Debian's Jérémy Bobbio, also known as Lunar, spoke at the Chaos Communication Camp about the distribution's efforts to reassert trustworthiness for open source binaries after it was brought into question by various intelligence agencies. Debian is "working to bring reproducible builds to all of its more than 22,000 software packages," and is pushing the rest of the community to do the same. Lunar said, "The idea is to get reasonable confidence that a given binary was indeed produced by the source. We want anyone to be able to produce identical binaries from a given source (PDF)."

Here is Lunar's overview of how this works: "First you need to get the build to output the same bytes for a given version. But others also must to be able to set up a close enough build environment with similar enough software to perform the build. And for them to set it up, this environment needs to be specified somehow. Finally, you need to think about how rebuilds are performed and how the results are checked."

Comments

Social Justice

[Anonymous Coward]

I'm confused - you say this is a Debian initiative, but I don't see how this promotes Social Justice, Inclusiveness and Diversity.

Re:Social Justice

[r.freeman]

I think that shit was done by Debian Woman, and by Gentoo, and by Sara Sharp. Not by Debian.

Re: Social Justice

[Anonymous Coward]

also, where are the backdoors for SPARTA?

sure as hell they exist. this is a diversionary show for the plebs.

just listen to jeb bush what he says about "all computers must be hackable" by crypto commies of his ilk.

Seems like a little random build size

[Revek]

Would make it harder for them to exploit.

Re:Seems like a little random build size

[Desler]

But that isn't the point of this. It's how to verify that your binary doesn't have tampered with source code.

Re:Seems like a little random build size

[Anonymous Coward]

That's completely orthogonal to this. This is about verification that a binary is built from a canonical source tree.

Re:Seems like a little random build size

[cold fjord]

That's a tricky problem.

Countering "Trusting Trust"

Re:Seems like a little random build size

[Desler]

Yes it is difficult. That's why they are trying to solve the problem.

Re:Seems like a little random build size

[MyAlternateID]

But that isn't the point of this. It's how to verify that your binary doesn't have tampered with source code.

I care about this, too. That's one reason I run a source-based distribution. It's not the only reason. It's not even the main reason. But it's one reason.

Anyone who really needs this kind of assurance was probably also building from source. You can do it once on-site, then make your own binary packages and push those to all of your other machines so it's really not bad. I think a much more insidious threat comes from malicious yet innocent-looking source, like what you find in the Underhanded C Contests.

It doesn't do much good to have a reproducible build of a program when it contains an innocent-looking yet malicious piece of code. Just consider Heartbleed. Whether Heartbleed was intentional or not, it proves that people can run vulnerable code for a very long time before it's found out, and that was a program intended to be secure.

Re:Seems like a little random build size

[Bing Tsher E]

I wonder, though, if an always-connected build machine could have compromised object files pushed onto it mid-build. It's a theoretical risk, but not one that couldn't be accomplished by a determined foe. The build process is well characterized for many projects, knowing when to push a rogue object file into the build directory wouldn't be that difficult.

It means the penetrating entity would need to already have access to your system, but 'object pushing' would be a useful technique for escalating security breaches.

Re:Peazip & DeadBeef Media Player

[Anonymous Coward]

Isn't deadbeef the name given to the roast beef sandwich between your mom's leg?

Gitian

[Anonymous Coward]

Gitian is a good start

Re: I have my apps check themselves... apk

[Anonymous Coward]

Hello, apk! I'm still struck by the admiration and respect I feel for your great achievement: your host engine.
Can you perhaps provide a systemd module for it? It would be really great!

Re:trust already lost in Debian

[Anonymous Coward]

i'm a fan of equality, so i'm not a fan of feminism, but how does this have anything to do with feminism?

Re:trust already lost in Debian

[Anonymous Coward]

on what at the roots amounts to a misguided feminist agenda

ELI5?

Re:trust already lost in Debian

[iggymanz]

you'd have to how the Debian internal politics have changed, there are articles about that and also about how it relates to systemd. even slashdot had one

This seems like a job for Virtual Box

[goombah99]

Wouldn't virtual box be able to do this? Then one only has the trouble of validating the virtual box. While that is actually probably harder to do you don't have to do this as often and one could use some open source virtual box equivalent and compile that from source.

On the otherhand I don't quite understand why, if one can compile the source, one needs to worry about untrusted binaries. Perhaps the intent here is for some master agency to watch for tinkered binaries or to post it's own Checksums apart from Debian. Then everyone has two sources for validated checksums.

Re:This seems like a job for Virtual Box

[wolrahnaes]

On the otherhand I don't quite understand why, if one can compile the source, one needs to worry about untrusted binaries. Perhaps the intent here is for some master agency to watch for tinkered binaries or to post it's own Checksums apart from Debian. Then everyone has two sources for validated checksums.

Almost right, except without the master agency. This isn't for the incredibly paranoid types who would already be compiling from source. This is for the rest of us, the lazy people who would rather "apt-get install foo" and just assume the distro's doing things right. If the builds are reproducible then eventually someone's going to verify them. If no variations are discovered, the rest of us lazy masses can be a lot more confident that we're not running anything unexpected.

Re:This seems like a job for Virtual Box

[Anonymous Coward]

From the article the issue was that the cia had found a way to own the *compiler* binaries and each program it compiled would have a vulnerability added at build time.

Re:This seems like a job for Virtual Box

[Anonymous Coward]

hale-fucking-luya

Build timestamps mess this up

[savuporo]

Unless you freeze system time for the full duration of the build, every piece of code that builds in __TIME__ or __DATE__ macros, will screw with this. Other environment macros injected into the build ( like git revision etc ) as well.

Re:Build timestamps mess this up

[wolrahnaes]

Pages 6 and 7 of the PDF linked cover time-related issues and basically agree, anything that builds time/date in to the binary is a problem that needs to be fixed.

Git revision on the other hand is a recommended solution, since it points at a specific state of the code and will always be the same if the code is unchanged.

Re:Build timestamps mess this up

[0dugo0]

Why would a lot of code need to be "fixed" just because someone anally retentive wants deterministic builds? If they truly care they can LD_PRELOAD fake date/time libs. I thought this problem was solved a long time ago by the bitcoin developers w/ gitian.

Re:Build timestamps mess this up

[Anonymous Coward]

you're an idiot.
there is NO reason to build in date time, it's dynamic and give no useful info about the code or binary that is not already given by a properly administered build, install, replication and file system.
and EVERY reason to build in the revision, it's static, and tells you exactly what rev the binary was built on.

Re:Build timestamps mess this up

[Ungrounded Lightning]

Unless you freeze system time for the full duration of the build, every piece of code that builds in __TIME__ or __DATE__ macros, will screw with this.

And I have run into this at my current employment, when checking that I had successfully selected the correct version of an archived source and reproduced the binary build. The source apparently had an instance of __DATE__ in it, and would compile differently on different days.

But the datestamps - at least in the tools I was using - were always the same length (so they didn't move other stuff around as they changed) and easily recognized. I could easily verify that the only differences were the datestamp.

Seems to me that it would be trivial to do a diff-like utility (or add yet another option to diff) that would determine whether files were identical EXCEPT for instances of __TIME__ and __DATE__ expansions - and report both the otherwise-match and the number and values of the date/time stamps.

Re:Build timestamps mess this up

[Anonymous Coward]

Yep hard problem, yep needs to be done;but there are a number of things that are also important that are also not being done but are /simple/ and /easy/. How about we start with :
1. insert OWASP dependency-check into the build to validate that the mess of third party libraries a component downloads are all free of /known/ vulnerabilities. *hint* that's not being don't because it would stop everyone from using open source...
2. automated static analysis of source to pick out questionable call syntax & call sequences
3. design driven testing to validate that you have the "right" tests to cover the purpose of the design
4. code coverage validation to ensure that all of the code is being tested.
5. Perfom actual design to solve the problem instead of stringing together a slew off-the-self-buzword-compliant-BS and calling it an architecture. That one is hard but used to be done before the the internet boom that made "time-to-market" more important than safety & security.
etc... all of these things are simple, and within our grasp to do. Evidence that Hadoop for instance ships with 194 /known/ CVE vulnerabilities in its third party libraries (OWASP dependency-check is quite eye openning) is proof that even the stupid simple things arnt being done of protect our systems.

Re: Build timestamps mess this up

[savuporo]

__FILE__ has a similar effect, as it refers to absolute path. Absolute build paths would also be have to be created deterministically, no temp directories or anything like that. And then, make sure everything that gets linked in statically, including the toolchain bits follow the same rules.

Re:Build timestamps mess this up

[Eunuchswear]

Why would a lot of code need to be "fixed" just because someone anally retentive wants deterministic builds?

Uh, because some anally retentive person wants deterministic builds? Did you RTFS?

Re:Build timestamps mess this up

[savuporo]

The other thing is to hack your build of the toolchain, so that __TIME__ and __DATE__ and __FILE__ could be stubbed and/or overridden by command line. Havent looked at GCC or clang codebases, but i would think it wouldnt be too hard.

Re:Build timestamps mess this up

[Forever Wondering]

When I needed to compare binaries, I wrote a script that would clean the source of __DATE__/__TIME__ and RCS/CVS style $Id stuff.

While the $Id was okay for source comments, it was common practice to add something like "static char *rcs_id = "$Id";" to each .c file in such a way that you'd get a bunch of these in the final binary.

This script can be run recursively on a copy of the source tree. Or, it can be done "on the fly" by having the script masquerade as gcc. Then, do the build.

This works a bit better than a special binary diff util because the $Id strings are variable length and could change the offsets [slightly] within many generated instructions.

RCS/CVS also had $Log for comments which pulled in the entire commit log into a block comment. This made even a simple recursive diff on the source trees of two different versions be messy.

Re: Build timestamps mess this up

[wolrahnaes]

I know this is Slashdot and all, but you really should RTFA. Again that's covered and a variety of solutions are offered, but you are basically right in that doing this right requires that those things all be the same where they're used.

The tricky part here is determining in which cases those sorts of macros are actually required and thus must be worked around versus where they can be replaced with something else to achieve the same goal (replacing time/datestamped builds with git commit IDs for example) versus where they were just pointless (embedding the hostname of the build machine in to the binary for example).

Re:Build timestamps mess this up

[wolrahnaes]

Why would a lot of code need to be "fixed" just because someone anally retentive wants deterministic builds? If they truly care they can LD_PRELOAD fake date/time libs.

The reason for deterministic builds is to allow those of us who want to use binaries from our distros for convenience sake verify that the binary is actually built from the source it claims to be from. It only takes a few people actually doing it to confirm things are good for all of us.

Basically it lets the lazy masses gain the same level of confidence in what they're running as those who compile everything from source.

I thought this problem was solved a long time ago by the bitcoin developers w/ gitian.

Bitcoin solved it as far as they needed for their own purposes, this project aims to solve it sufficiently to be generally applicable across the entire Debian operating system. The goal is that the entire Debian binary package repository could be audited by anyone who cares to do it. Obviously if it's generic enough to cover all of Debian the same techniques should be usable pretty much across the entire computing world.

I have my apps check themselves... apk

[Anonymous Coward]

See subject: Via this method-> http://it.slashdot.org/comment... (Did ok here CODING FOR DEFCON in 2005 (my compressed/packed exe + sizecheck @ startup technique)).

* This can also be done via alternate methods like CRC checks too...

(I'm honestly surprised more app makers don't do this to be blunt about it... it works).

I don't compress the exes anymore (triggered false positives) such as in APK Hosts File Engine 9.0++ SR-2 32/64-bit -> http://start64.com/index.php?o... BUT I still perform that self-test of itself @ its initialization for the reasons noted in the 1st link above & below...

APK

P.S.=> I'm not sure what they're out to prove or do here, but this helps function that way for trustworthiness of an application & verifying it's the original build size by doing the above - which also functions as a "built-in" native to the app itself virus checker too (since 'traditional exe viruses' attached themselves to the tail of an executable & alter the jump tables to work, but ADDING SIZE TO DO SO which this method catches in that capacity)... apk

Debhat only needs one binary

[Anonymous Coward]

systemd

Re:I have my apps check themselves... apk

[Anonymous Coward]

I don't compress the exes anymore (triggered false positives)

Ah, so Khyber was TELLING THE TRUTH about AV software detecting your shit having viruses. And from what I am reading, not once did they mention anything about it being a false positive. Of course, given risks on the internet now days, I wouldn't expect them to keep the file on their system if its suspect, so I don't blame them for not investigating further.

How about you eat crow and go apologize to them for your own incompetence and lack of foresight?

Awesome

[trawg]

I was thinking about this being a problem a while back - how to deal with building something from source and knowing I was getting the same output that the developers wanted me to have. Coincidentally about the same time, a href="http://developers.slashdot.org/story/13/06/20/1548228/are-you-sure-this-is-the-source-code">this article popped on Slashdot and introduced me to Ken Thompson's article Reflections on Trusting Trust - a great read and something that really opened my eyes (in that wide-open-because-of-terror kind of way).

Also from that thread came this email from one of the Tor developers talking about their deterministic build process to do the same thing.

I think this is a problem that would be really great to solve as soon as possible. I very much hope that once we start seeing more reproducible builds we don't suddenly find out that certain compilers have been compromised long ago.

Re:Awesome

[Forever Wondering]

The problem solution can get messy.

Most packaging systems have a control file for each package that specifies dependencies for other packages with versions, conflicts, etc. They specify deps for stuff they care about (e.g. gtk3 version X needs cairo version Y) but they don't always specify the version of gcc et. al. that they need, because that's not important from their perspective. That is, they're happy to build with gcc 4.0.0 or 4.1.0 or whatever. Sometimes the deps are specified as "I need package X with version >= 2.6"

To be reproducible, these packages would need to spell out exact versions for the build tools and possibly/probably the exact version for any given package it depends on. It's a bit inflexible to burden an individual package with specifying an exact version dependency [and can break a lot of stuff], so generating an "uber" version/dependency file during the "make world" seems like the sanest approach.

But, that may not work either. When distro major releases are done, they can do "make world" and get the exact versions for all packages. But, sometime later, a package may be updated to a new version. For example, it's a forward/backward compatible bug fix to a shared library, so application program packages that depend on it (via rev >= X) don't need to be rebuilt.

Also, if a given package has a dependency like "gcc >= 4.0.0" [because it needs a given feature that was added in 4.0.0] may work fine for a while. But, later the package control file may have to be changed to "gcc >= 4.0.0 && gcc " need to be rebuilt, just to verify that the stat.h change builds the same binary? Further, maybe some apps may be updated to use this new define. It would be easy for a programmer to see that merely adding a #define is harmless and backwards compatible. That is, the smart way is use the latest stat.h even for older programs as they will build the same binary regardless of which version is used. But, a validation would have a hard time determining this and would have to rely on package version numbers.

Existing package systems do have a fair number of extra fields to help with such a choice (e.g. "I'm version x.y.1 and I'm backwards compatible with x.y.0"). But, can/should a validation system rely on this? IMO, it must disregard this and still regen the package and do the compare to detect mistakes in the package control file. That is, the only proof is the final binary comparisons, regardless of what the control file says.

Now comes the fun part ...

Naively, the validation system could loop through all packages and rebuild a container, virtual machine, or even just a simple chroot target directory with the correct dependent package versions for the given package that you wish to validate. Most of the the time would be spent simply extracting the packages in order to get the canonical environment for the build/verify operation.

Far better would be for the validation system to build the container initially and just change dependent packages as needed. But, this would require the validator to do global analysis of all of the dependency graph and choose the best way. For example, you'd like to install gcc 5.1.0 and verify most packages, deferring those that need the newer 5.1.1 until the end. Flipping back and forth would be wasteful and it's desirable to avoid this "thrashing".

But, such global analysis requires a satisfiability solver of some sophistication (e.g. libsolv) or you end up with massive amounts of cycles consumed.

As to disk space ... I've been using fedora and do "reposync" so I have both binary and source rpms. For a given fedora version (e.g. fc21), this runs to ~200GB for everything, which is what you'd need on each system if you wanted to "crowd source" the validation effort.

Re:Soon to be assimilated

[Anonymous Coward]

At least systemd doesn't have maintainers that just randomly comment out lines of code in security software based on unverified, false positives from a static analyzer.

No but it does have a bunch of assholes determined to shove it down our throats no matter what, using all sorts of politics and other "not based on technical merit" tactics to make this happen. If I ever run systemd (not likely, but possible) it sure as hell won't be because somebody else decided I should. If I wanted somebody else to decide what was on my system, I would run a commercial OS and be done with it.

I find the Wiki page on systemd to be exquisitely ironic. In the first paragraph or two it says "The name systemd adheres to the Unix convention of making daemons easier to distinguish by having the letter d as the last letter of the filename." Well that's great! At least there is one single thing about systemd that can be said to follow the Unix way of doing things. And here I was thinking there were none at all.

Awesome - on trusting trust

[trawg]

I was thinking about this being a problem a while back - how to deal with building something from source and knowing I was getting the same output that the developers wanted me to have. Coincidentally about the same time, this article popped on Slashdot and introduced me to Ken Thompson's article Reflections on Trusting Trust - a great read and something that really opened my eyes (in that wide-open-because-of-terror kind of way).

Also from that thread came this email from one of the Tor developers talking about their deterministic build process to do the same thing.

I think this is a problem that would be really great to solve as soon as possible. I very much hope that once we start seeing more reproducible builds we don't suddenly find out that certain compilers have been compromised long ago.

Re:Awesome - on trusting trust

[Anonymous Coward]

Alas, your duplicate post here is not reproducible. It differs slightly form the original.

Re:Awesome - on trusting trust

[Anonymous Coward]

>I think this is a problem that would be really great to solve as soon as possible.

Have fun with that. The binaries emitted are more or less guaranteed to change every time the compiler is updated.

Re:Awesome - on trusting trust

[Ungrounded Lightning]

The binaries emitted are more or less guaranteed to change every time the compiler is updated.

Sure.

So you compile it with the (perhaps out-of-date) toolset, getting a match to the distributed binaries, then again with the latest-and-greatest toolset if you want to use its output rather than the standard one (and take your own chances that your new compiler revision was compromised.)

The problem being addressed is making sure that your own build environment contains the same source and makes the same binaries as the distribution version, so you know that you have uncorrupted source and an uncorrupted toolset (or as close to it as you can reasonably expect to get - which is pretty close, given that you can apply the same techniques to the tools themselves). Then you can join, and take advantage of, the large "group of eyeballs" checking the source (and build system) for malware inclusions.

Bitcoin solved this by using gitian

[Anonymous Coward]

Bitcoin solved this by using gitian. It builds inside a VM.

https://gitian.org/

Re:trust already lost in Debian

[i.r.id10t]

So... what to do then? What other distribution works well, has the large amount of packages available, is freely available (not a big deal since RH isn't going to be systemd free), and pretty much Just Works?

Freebsd

[Anonymous Coward]

Compile your own binaries using ports on freebsd. :)

Oh, and no systemd there either.

OpenBSD LiveCD

[Anonymous Coward]

if only...

I Don't Get It

[jmac_the_man]

What does this solution provide that checksums do not? If you trust Debian's repositories, and they publish checksums and build sizes, you can independently verify that the package you downloaded is the one they published. As an additional level of security, they can use signed binaries, where they encrypt the binaries with a private key, and then, if you trust Debian's repositories, you decrypt their binaries with their public key before you install them. IIRC, Debian already uses both of these.

I mean, clearly the Debian guys have thought of this, so what am I missing?

Re:I Don't Get It

[jopsen]

validation of source to binary step... This is so you don't have to trust their binary... but can read their source and trust that it is in fact the source for the binaries..

Re:I Don't Get It

[Anonymous Coward]

They are trying to ensure that the Step 1 in the process is clean. (aka, why try to poison the water in the cup if you can just poison the well to begin with.)

Yes, but can you trust your compiler tool chain?

[laing]

This only works if Debian can guarantee the integrity of the development tool chain. See this >30 year old talk/paper by Ken Thompson describing the problem. Once inserted, the malware is persistent and invisible. Re-compiling your compiler and applications from known-good versions doesn't help.

Re:trust already lost in Debian

[Bing Tsher E]

NetBSD has the pkgsrc collection, which is fairly large, and it is never going to be polluted by systemd.

Re:trust already lost in Debian

[Anonymous Coward]

So... what to do then? What other distribution works well, has the large amount of packages available, is freely available (not a big deal since RH isn't going to be systemd free), and pretty much Just Works?

OS X.

Re: I have my apps check themselves... apk

[Anonymous Coward]

Post the source or it's a virus.

Compromised hardware

[fabrica64]

What about compromised CPUs? If you are the NSA I think it's easier to build a backdoor into the CPU than try to keep up with ever changing software builds. Isn't it? CPUs are totally controlled by three or four U.S. companies, are closed source nobody has ever seen into it...

Re:Compromised hardware

[caseih]

A partial answer to this is to build your own CPU and system in software. Like Bochs. But you could build this virtual system on any number of other completely incompatible platforms for verification. Would be slow. But at least it would be consistent and verifiable. You couldn't use hardware virtualization for this. Would have to be completely implemented in software. And if different people implemented the same reference platform independently (using their own preferred language and programming techniques) that would add an additional layer of verification. Even the deepest NSA compromise would have a hard time completely influencing this.

Re:Compromised hardware

[Anonymous Coward]

Two points. Firstly, there is a large swath of non-NSA adversaries who could exploit the lack of reproducibility in builds today. Even if your only adversary is the NSA, it's cheaper to exploit software and distribution paths than to exploit chips. Raising the cost of an attack is a worthwhile countermeasure, even if the attack is still ultimately possible, even against the NSA.

Secondly, how exactly do you surmise a CPU attack would work here? Are you thinking of something that causes the compiler to emit a modified binary? What about when the compiler's source changes, or the source being compiled changes, or when another program that isn't the compiler triggers the same instruction sequence? Compiler developers have to look at the output of the compiler all the time, it's not like they aren't going to notice if the output suddenly changes in a way that completely doesn't match the code for their own compiler.

Or were you thinking of something way out where the CPU has a secret access code to ring 0, possibly from an I/O port? Local privilege escalations are hard to prevent with a modified CPU because the CPU is mostly in charge of enforcing it (really the MMU does the enforcement, but the CPU tells the MMU what to enforce), while remote privilege escalations are going to become harder with IOMMU preventing undesired communication between components in the computer (ie. your network card sending an out of band signal to the CPU causing it to enter backdoor mode). The problem with such a capability is that it requires cooperation between different hardware and software parts that may be made by different vendors, and that it's hard to use it in a way that isn't detected.

Re:Compromised hardware

[dwheeler]

If you're worried about compromised CPUs being used to compile executables that are used by others, then reproduceable builds are a great countermeasure. Just use reproduceable builds on many different CPUs, and compare them to ensure they are the same (for a given version of source and tools). The more variations, the less likely that there is a subversion. If what you're compiling is itself a compiler, then use diverse double-compiling (DDC) on many CPUs.

If you're worried that an INDIVIDUAL may end up with a compromised CPU, then yes, it's much harder to counter attack. On some systems, you can isolate the system (no network traffic, etc.). That said, an adversary has to send packets to subvert a specific system, then every time they do the subversion they risk being detected, so it's far less likely to be used for bulk surveillance... it would more likely be one well-resourced organization (e.g., a government) working against another well-resourced organization.

Re:Compromised hardware

[Anonymous Coward]

https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

More worrisome and long known.

Re:Compromised hardware

[Anonymous Coward]

What about compromised CPUs?

OK, that doesn't really matter. What matters much more, and what Debian repeatable builds don't handle, is compromised upstreams. Debian Developers don't have the resources to audit changes from upstream packages. Some, like Firefox, don't even have resources to backport fixes since codebase changes so much between versions. So, in effect, the simplest ways some nefarious agency can compromise projects is via upstream code contributions.

If they do it as a DD, modify a package, that can be spotted. If they hax the binaries, that is automatically spotted by signed binaries. If they hax DD's computer, that can now be spotted via repeatable builds. But breaking upstream code, like Linux kernel or Firefox or Qt or Gnome, well, that is a little more straightforward considering the code churn. It may not be easy, but upstream route is the easiest and least likely to be spotted.

As an example, see the FIPS random number generator compromise. That is as upstream hack as you can get!

Re: Compromised hardware

[Anonymous Coward]

simply open the mmu gate when the 128 bit sesame word is being processed by cpu.

the obly real solution is what the russkies do with their elbrus cpu. build own silicon.

Re:Compromised hardware

[Anonymous Coward]

There are quite a few Mono-Instruction-Set-Computers (MISC?!) which can point to easy implementations of this (not always so easy to program).
Have a look at Linux's Coffee HOWTO and check out for SBN (Subtract and Branch if Negative); it can be implemented with 2, 3 or 4 operands.
That last case is quite interesting, since it has superb performance characteristics for anything that matter in compiling processes. F.

BadBIOS and more

[Anonymous Coward]

https://www.reddit.com/r/badbi...

I bet all hardware is pwned - check it out, some serious shit!

VirusTotal says it's no virus... apk

[Anonymous Coward]

See subject: 57 antivirus programs say so + MalwareBytes' hpHosts Admin (MalwareBytes employee) hosts & recommends it -> http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus per this VERY recent testing of them all http://www.av-test.org/en/news...

(MalwareBytes' hpHosts admin HAS the sourcecode & verified it clean as well - hence, why he + others in the security community HIGHLY RECOMMEND it as well as host it! You wouldn't BELIEVE what they put me through for all of this testing either... & I passed them all as clean/safe!)

&

It's GUARANTEED safe & clean per it being checked by 57 antivirus programs recently in BOTH its 64-bit model https://www.virustotal.com/en/...

+

In its 32-bit model also https://www.virustotal.com/en/...

APK

P.S.=> I don't owe ANYONE here a view @ my work after the above, that's certain - considering most here don't code (or they'd have work of their own out there, 99% here don't) & wouldn't understand it anyhow!

+

I personally consider much of the "Open SORES" movement largely a code thieving system!

Face it - "all those eyes on the code" don't stop ANDROID infestations galore daily almost

&

Their INFERIOR browser addons like "AlmostALLAdsBlocked" (paid off to NOT DO ITS JOB & crippled by default) http://www.businessinsider.com... are exactly that - inferior in not doing as much for security, speed, reliability, & anonymity from any SINGLE one of them vs. hosts, + they're less efficient as well in terms of resources consumed, by FAR, as well! apkb

The stupidest part of open source

[Anonymous Coward]

So many times, I've downloaded the source of something, and been completely unable to build it, because the build environment/libraries/dependencies/whatever was not specified.

While there are occasionally step by step instructions of what to install, there most commonly isn't, and the "developer" doesn't have a fucking clue.

In many cases, the problem is solved by using a different version of the compiler - the precise version the dev uses - which is utter bullshit. It's like needing to use a certain brand of oven to bake your cake.

Debian, and all programs, should ALWAYS have been able to be compiled by anyone to achieve the same binary. Isn't that the purpose of make files?

From a technical standpoint, I understand why this occurs, but from a technical standpoint, it should have always been avoidable, and the ball was dropped - by practically everyone - a long time ago.

Re:The stupidest part of open source

[ledow]

I have to say - necessary compile environments really put me off coding projects.

Just having a Makefile is not sufficient. Even having all the right versions of prerequisite libraries isn't sufficient. Sometimes you have to patch and tweak and pass parameters and all kinds us to build the damn thing properly.

Lots of software is like this. Especially when you work on a non-standard platform, even ARM, or with certain libraries (ffmpeg! grr!).

Let's not even get into what happens when it compiles against some ancient version of an obscure library even if it barely uses it.

We really need a way to specify this kind of thing. There needs to be an XML format with namespaces that specify - down to the version, source file and original location - what the original prerequisites were for each particular build. Hopefully that's what they are working towards.

P.S. This is a MASSIVE killer for teaching programming students. Introduce them to C, everything is fine. Get them to compile against a particular library - even SDL which is quite portable - and you can be in for a world of hurt. Compile on something unusual like MinGW and you're back to the command line hand-compiling some of these libraries with dozens of switches and path-overrides just to compile a simple Hello World example.

Re:The stupidest part of open source

[gl4ss]

gradle and some other stuff is basically like your suggestion.

specify repos, names and version(s)/ranges that you want and build.. in theory anyways.

Whats the point?

[tuxgeek]

Alas, Debian once was the standard that other Linux distributions were measured by.
Fast, stable, dependable, reliable, secure, usable.

Not so today, since they decided to pour bucket loads of experimental garbage code into their base, that the distribution can give the Gnome Desktop user a more Windows like experience.
Note: Nobody uses Gnome anymore. Move on ..

To be fair, a Linux distribution with training wheels (systemd) could be helpful to those wishing to migrate away from M$ addiction, and have a system to learn the linux desktop on. But changing the entire Linux ecosystem for this experimental bloat was suicide.

Thankfully, FreeBSD has reached a maturity that Debian/Linux purists can migrate to, and can still have a safe and secure, modern, state of the art, desktop system, their way, without the squirrelly flashy wizbang bloated garbage that has now infested the Linux world.

Re: Whats the point?

[Anonymous Coward]

at some point they will try the same with freebsd. but at this point either theo pisses the commies off or the smart folks have done something like AnonSecuros. small, secure, stable for decades...

Re: Whats the point?

[Anonymous Coward]

I don't think Theo gives a flying fuck what FreeBSD does.

Re: Whats the point?

[Anonymous Coward]

I don't think Theo gives a flying fuck what FreeBSD does.

But once he's destroyed Linux, he'll need a new target.

Re:Yes, but can you trust your compiler tool chain

[Anonymous Coward]

Write Your own compiler?
AFAIR You could write a half decent LISP interpreter in a weekend, starting from virtually nothing. You are basically writing a basic -calculus to machine language code, and then it magically becomes self-hosting.

Re:Yes, but can you trust your compiler tool chain

[Anonymous Coward]

See this paper describing how to counter that problem. The trusting trust attack is not the end of software security.

Re:trust already lost in Debian

[Anonymous Coward]

They're forums sliders attempting to bury other conversations. It's what idiots like that do and why they do it. If you've never heard of forums sliding look it up. They do it above posts that are posted earlier than ones they want buried by making replies to the earlier posts (often off topic and stupid like you yourself state).

Re: trust already lost in Debian

[Anonymous Coward]

Again we see the immaturity of the systemd kids. For us adults, concepts like stderr, syslog, and exit statuses are concepts critical for managing a server. We understand and embrace the UNIX-way. If those kids spent as much time learning UNIX as they did posting childish rants, they'd why people don't like systemd.

Diverse double compiling (thanks dwheeler)

[tepples]

So long as two or more independently developed, self-hosting compilers for a language exist, with at least one as publicly available source code, a Ken Thompson attack on the public-source one is infeasible. David A. Wheeler proved it; here's the gist:

1. Use Visual C++, Intel C++, and Clang++ to compile g++. The binaries you get in this stage will differ, but if VC++, Intel C++, and Clang++ are uncompromised, they will have exactly the same behavior.
2. Use each of the three copies of g++ you compiled earlier to compile g++, disabling timestamps in the output. Because they all have the same behavior (the behavior of g++), they should all produce the same the output. Thus the binaries you get in this second stage will be identical unless one of the first compilers is compromised.

Re:Diverse double compiling (thanks dwheeler)

[Paul Jakma]

No he didn't prove it is infeasible. For one, that would require a method to prove that the compilers are indeed wholly independent, which hasn't been provided. Also, note that people in some sub-field of technology tend to move around. An engineer who has worked on one compiler is *more* likely to also work on another compiler at some stage than any random engineer. The DDC technique *assumes* that diverse compilers are independent - it takes it on trust. Wheeler's work if anything re-inforces the essence of Thompson's philosophical point, that we must either completely build and control every aspect of our system OR we must trust to at least some degree in someone else. Note also that someone can frustrate this technique by deliberately making their software not build reproducibly, for apparently innocent reasons (e.g. D Wheeler had such issues with using tcc for DDC). A fuller version of my critique of "Diverse Double-Compiling".

That sounds like I'm being very dismissive of DDC, but I'm not. It could be really useful, *if* it is feasible to actually regularly reproduce builds. Debian is working on this, and hopefully they'll get there - but it's not a trivial task either. However, DDC does not fully counter Thompson's attack - not in the normal absolute sense of the word "fully" at least.

Re:Diverse double compiling (thanks dwheeler)

[Anonymous Coward]

That all assumes that the operating system's kernel has not been subverted to alter the programs while they are written to disk, much like north korea's north star linux does with watermarks in documents. Therefore, you'd have to cross-compile both g++ and the binaries you want to verify on two different platforms.

Re:Diverse double compiling (thanks dwheeler)

[Paul Jakma]

And the end of that comment still sounds more dismissive than I wanted... Take 2:

I'm not being dismissive of DDC. Distros regularly attempting to get reproducible builds with diverse compilers will raise the bar and make attacks harder if it can be done, and additionally it will help catch bugs. However, DDC does not fully counter Thompson's attack, and it is good to remain aware of the assumptions it operates under.

I.e. could be a very nice step forward, though it is important to note the "fully countering" isn't quite "fully" and there are limitations.

Easy enough to handle trusting trust

[raymorris]

Since you mentioned Reflections on Trusting Trust, that issue is easy enough to avoid. There are some simpler and more clever methods, but consider this:

Use Borland 1.0 to compile llvm.
Use this new llvm binary to compile gcc.
Chain a few more in you want to.

You don't need to trust the first compiler. It could be trojaned so as to trojan new copies of itself. You'd only be concerned if you thought that Borland 1.0 was trojaned in such a way as to add a trojan to the code of a compiler that didn't yet exist, llvm, AND that trojan wasn't for Borland or llvm, but for the current version of gcc - another compiler quite different from anything that existed when Borland 1.0 was created.

The perpetrators would have to not only be astronomically clever, they'd also have to see into the future, twice, in order to build such a trojan.

Re:Easy enough to handle trusting trust

[Anonymous Coward]

or, simply hack binutils ;-)

have a look at AD Wheeler's Diverse Double-Compiling to get the description of the more generic technique countering Ken's Trusting Trust challenge.

also, have a look at EasyBuild which a tool specifically made to automate such processes. F.

Re:Easy enough to handle trusting trust

[Paul Jakma]

Why do you think a new trojan can not infect old binaries?

The Thompson attack is what we would recognise today as a class of virus. Indeed, as Thompson's point was a general one about the unavoidable need to trust others, if one did not build every component capable of basic logical manipulation oneself, to fully counter Thompson's attack you would have to be able to counter every possible kind of virus and rootkit - and not just of the software, but also of any other firmware and microcode that might handle or be involved in running your code. (Read his paper, he is clear he envisions his attack could be implemented in lots of ways and places in the abstract).

Re:Easy enough to handle trusting trust

[Paul Jakma]

Good thing there are no well-known, stable hooks in programmes to allow code to be run in a generic fashion, as part of, say, binary file formats. Oh wait...

Re:trust already lost in Debian

[Eunuchswear]

You do know that you sound like a crazy person, don't you?

Why are they not doing this already?

[McLae]

I was doing this 15 years ago. Your build document specifies the build computer (Brand, model, OS version, etc.), the tools needed to do the build (Compiler(s), Script to code translators, etc., with exact versions), and the source version, with instructions on how to pull that version from the repository. And all the steps in the build.

Our build package included copies of the OS install CD, install media for any tools needed, and the complete code set as text files.

You wipe the disk on the build machine, install the OS, install tools, run the build, and you get a known result.

This should be standard procedure for any software released to the public (Or purchaser). If not, you are open to chaos with releasing software. (Been there, as user. Not fun!)

Thomas, DeSoto, TX

Re:Why are they not doing this already?

[Anonymous Coward]

I would posit the simplest answer to your question is- The NSA is happier that way, and has (moreso pre-Snowden) had the means to keep this subject deprioritized in the minds of the most relevently influential people.

Re:Why are they not doing this already?

[allo]

But i guess your binaries still had a different checksum. For example because of timestamps. So you need to analyse byte-by-byte, what are the differences and if they are unimportant. Now you get the same binaries and do not need to check anything further.

Domain Software Engineering Environment

[Anonymous Coward]

The reproducibility problem was solved in the 1980's by the Domain Software Engineering Environment (DSEE) of Apollo Computer, Inc. Apollo produced both hardware and software ["not quite UNIX"] which competed with early UNIX graphical workstations. The source code control of DSEE was on a par with git. In addition to the version of the source, the output of a build also recorded the identity (name and version) of every tool and library which affected the output. Reproducing a build involved reproducing the entire build environment, including all tools and libraries; and it was possible to branch within that environment (creating a new version that contained a patch, for instance.) There was enough shared caching and symlinking to make it usable, although a fresh start from a not-recently-used root could take a while.

Re:I overturned 7 false positives easily

[Anonymous Coward]

The biggest obstacle to people running your hosts program: you. If you were selling a commercial product, any competent marketing manager would tell you to stay behind the scenes and shut the fuck up while they attempt to be professional.

Bragging about your lack of posting limits? While complaining that others abuse things? Hah. But somehow in your deranged TimeCube mind you will convince yourself that you scored some great victory.

I don't take the advice of spammers. I don't use their programs. I don't take them seriously. You have a couple of sycophants but other than that, everyone else here thinks you're an obsessive nutjob. You never did answer the question: have you been diagnosed with any kind of mental or emotional illness? Answering that question entails saying "yes" or "no", in case you're unclear about how to directly answer an unambiguous question.

Re:trust already lost in Debian

[Barsteward]

well, vote with your feet and go off to devuan and stop polluting a non-systemd article with your immature and incorrect rant

Re: trust already lost in Debian

[Barsteward]

Again we see the immaturity of the anti-systemd kids. - just fixed that for you, didn't bother with the rest of your cut and paste post because it just shows just how little you know.

Re:I overturned 7 false positives easily

[Anonymous Coward]

stops you from getting infected in the 1st place by blocking known sources of infestation...

You mean the Internet?

Given..

[Anonymous Coward]

That when you consider compiler bootstrapping and generational compile vectors for inserting attacks "in the middle" I hope they take the step to create or audit a very clean bootstrap path to a known version of the compilers. Else no matter what is done, a series of "slow-change" modifications to the compilers over years could leave the system wide open to unrecoverable backdoors.

Re: Soon to be assimilated

[Anonymous Coward]

or uae freebsd or l4. the commies have discovered informatics. let them fsck wirh linux...

Re:trust already lost in Debian

[r.freeman]

systemd is hihgly gay, and was pushed into debian thanks to debian woman and other non-sense, not-technical "arguments".

Re:I overturned 7 false positives easily

[Anonymous Coward]

Until you've done better or prove him wrong, take your own advice, shut the fuck up and get on topic troll.

I've done better. I do better all the time, by not spamming some stupid program on a forum filled with people who don't give a shit. I do better all the time, by using multiple overlapping tools for security and not psychotically insisting that said stupid program is The One True Way. I do better all the time, by conducting my own arguments instead of having to hide while little dick-sucking sycophant myrmidons like you do it for me.

Re: Soon to be assimilated

[Anonymous Coward]

The systemd guys are young and energetic.

and foolish.

Re: Soon to be assimilated

[mynamestolen]

I think you missed the sarcasm

Re:I overturned 7 false positives easily

[Anonymous Coward]

You haven't done shit you lousy little useless bum. If you did you'd show it. You can't.

already being done in gaming machine builds...

[chriskenrick]

I used to work for a manufacturer of poker(slot) machines and hybrid/table casino games, and this was a non negotiable requirement. A given set of source code had to produce exactly the same binary output, to the point where you'd get identical checksums when verifying it. Furthermore, external test labs responsible for certifying the software also needed to be able to build the software from source, and verify the binary in the same way.

The biggest headache in the process was anything that included a date time stamp in the object code or final binary .. from memory there was some part of the build process that would reset all those date stamps to a fixed value. A virtual machine as a build box was also the only reasonable solution for guaranteeing a very locked down, but easily cloneable build environment (before that we were resorting to supplying physical build machines to each test lab)

Tor Project Writeup on Deterministic builds

[whh3]

Part 1
Part 2

Re:Yes, but can you trust your compiler tool chain

[Henning Rogge]

This only works if Debian can guarantee the integrity of the development tool chain. See this >30 year old talk/paper by Ken Thompson describing the problem. Once inserted, the malware is persistent and invisible. Re-compiling your compiler and applications from known-good versions doesn't help.

The problem got a lot more complicated for the attacker today... Thompsons attack works well if there are only a few architectures and only a single compiler. But the attack complexity grows exponentially in the presence of multiple architectures (that can be used to cross-compile each other) and multiple compilers (that can compile each other). Now you need a compiler virus that not only compiles on all architectures well, it also needs to detect all kind of compilers that are there and works on all versions of them. The "reproducible build" system makes it even worse for the attacker, because its easier to to compare the results.

Re:trust already lost in Debian

[Anonymous Coward]

Mod Parent Funny

I overturned 7 false positives easily... apk

[Anonymous Coward]

See subject: NOD32, Comodo, McAfee, Sophos, EmsiSoft, ArcaVir, & Qihoo360 rescinded those false positives, & the link below is further proof of that as well!

I proved that they found my 32-bit COMPRESSED model of my program a "virus" yet NOT my 64-bit one - & the folks @ MalwareBytes' hpHosts (who helped me thru this no less & HOST + RECOMMEND my program -> http://hosts-file.net/?s=Downl... ) have its sourcecode WHICH IS THE EXACT SAME IN BOTH MODELS (except for resource strings that say "32-bit" vs. "64-bit" to differ both models in their GUIs) so they knew they couldn't say 1 is a virus, the other not, when they're exactly the same.

Face facts (since you downmodded the last time I posted this to try to "hide it" since you failed -> http://linux.slashdot.org/comm... )

* You FAIL, troll (Khyber posting by ac no doubt)...

(Some of the "rules" the fools @ these companies use aren't right, & I've proved that above on COMPRESSED EXECUTABLES ALONE - some do it if you use a WinRAR SFX installer, which is NOT A "VIRUS" EITHER... most everyone in the security community knows it!)

FUNNIEST PART IS HOW THE ANTIVIRUS MAKERS TRY TO SCREW EACH OTHER OVER THAT WAY -> http://www.theregister.co.uk/2...

As well as how SYMANTEC literally ADMITTED ANTIVIRUS IS NOT VERY EFFECTIVE AS A DEFENSE ANYMORE too -> http://dottech.org/157355/syma...

* Whereas my program (proven clean MANY times shown above AND below too), stops you from getting infected in the 1st place by blocking known sources of infestation...

APK

P.S.=> As to Khyber? He's an imbecile (I shot him down easily on many points regarding that & other technical matters)-> http://linux.slashdot.org/comm... which you downmodded to try "hide" too, Khyber posting as ac now... apk

Proof Khyber's an imbecile... apk

[Anonymous Coward]

"NOD32 detects a trojan in APK's HOSTS bullshit." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

VirusTotal & NOD32 SHOW IT COMPLETELY CLEAN IN ITS EXES

https://www.virustotal.com/en/...

AND

https://www.virustotal.com/en/...

There's only 2 exe's & 5 text files in it - The exe's are proven clean as shown above in the 2 links from VirusTotal, the installer's a SFX rar (keeps it 2mb smaller on download) - that's NO virus!

(Unless YOU know of a way that .txt files are "viruses")

---

"he's tying to get your fucking information." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

My program doesn't transmit outward ONLY intake of data from 10 reputable sources in the security community!

---

"APK is apparently too fucking stupid to do this at the ROUTER level where it's most effective" - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

You believe in "eggshell security" which fails per -> http://www.theregister.co.uk/2...

A TRULY COMPETENT NETWORK ADMIN WOULD DO FAR MORE THAN MERE PERIMETER LEVEL SECURITY @ ROUTER LEVEL!

(Right down to the endpoints/network nodes level in PC workstations also using tools you already have in hosts + firewalls (vs. "piling on 'MOAR'" that's inefficient & not nearly as effective in slower usermode browser addons)).

---

"Windows 10 has hardcoded IPs and bypasses HOSTs." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

Windows ONLY bypasses hosts files for Windows update (Win8 & below) & for the tracking "telemetry" in Windows 10 - test it yourself.

---

"Browsers can bypass HOSTs as well." - by Khyber (864651) on Saturday August 22, 2015 @01:02PM (#50370415)

WTF? They'd be bypassing the IP stack itself, hosts are part of it - since that's impossible? You've proven yourself a moron, again.

APK

P.S.=> See subject + the above, & "EAT YOUR WORDS", Khyber... apk

Borland CDs are read only

[raymorris]

> Why do you think a new trojan can not infect old binaries?

CD, and floppies with the tab set, are read-only. Unless this virus changes the physical properties of aluminum, your old Borland CD isn't going to get infected.

Re:Borland CDs are read only

[Paul Jakma]

You can't run a compiler from read-only media though.

Re:Borland CDs are read only

[metrix007]

Of course you can, it just needs a writable working directory.

Re:Borland CDs are read only

[Paul Jakma]

Perhaps I wasn't being explicit enough.

The CDROM might be read-only, but the software has to be copied into memory by something in order to run. As per Thompson's original point, it isn't sufficient to protect one piece of the system. As he stated, his attack implies that *every* programme that is involved in the handling of software must either be validated to the same level as having written it yourself OR you must invest trust:

In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program ..

(emphasis mine).

Indeed, his point on trust extends beyond just programme-handling programmes to all logic (soft or hard) involved in the handling and the running of software. Thompson mentions microcode almost after the text above:

As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.

Since Thompson, we've had "Blue pill" rootkits that use x86 virtualisation features to effectively run themselves as microcode under the victim system (and unbeknownst to).

Is this even possible?

[Anonymous Coward]

First you need to get the build to output the same bytes for a given version.

Admittedly I haven't even looked into the eccentricities of open source compilers, but... if you look at the Microsoft compilers, for example, they don't even produce the same output bytes from the same compiler for the same source code input. Their output is "close", but Microsoft's compilers include something akin to a timestamp in the executable headers that is different for every invocation.

Nixos does this

[Anonymous Coward]

The hardest part is keeping an identical build environment. Nixos is specially designed to do so: https://nixos.org/

It's been necessary since Ken Thompson's bsd hack

[Tesseractic]

I applaud this initiative, and it may make me switch back to Debian as my OS of choice.

The trusting trust problem is a serious one, and if you can't rely on being able to build a
byte-for-byte identical unit from source, you can't really have any confidence that you're
running code that represents what the authors intended.

  - I used to be a perfectionist - now I am much better; I know how to compromise.

Borland predates Linux, ELF

[raymorris]

Are you under the impression that the DOS .exe files produced by Borland 1.0 are approximately compatible with Linux ELF files? Maybe you're thinking that because neither are Windows, Linux must be DOS? No, there's nothing "stable" between the two completely different formats. So the Borland compiler couldn't possibly include a trojan for an operating system that didn't yet exist, using an executable format that didn't yet exist.

Re:Borland predates Linux, ELF

[Paul Jakma]

I'm not familiar with DOS exe format. However, there must be some well-defined entry point.

Thompson's attack doesn't mean that any subversion of the Borland 1.0 compiler is limited to when the Borland 1.0 compiler was created. Thompson was making an extremely general point about security in programmable systems: You either build pretty much all of it yourself, or else you must invest trust in others.

not trusting is hard work

[raymorris]

Well, since you're not familiar with either format, let me give you an analogy. Go build a mold for making intake manifolds to fit all 2040 model year cars. That's essentially equalivent to what Borland would have had to do in order to include a Linux elf trojan in the 1980s.

The Thompson paper reminds us that the normal workflow involves trusting the toolchain. It in no way indicates that we can't choose a paranoid workflow instead. One type of paranoid workflow involves validating our modern tools by using much older and much different tools. Because attackers of the 1980s couldn't predict the future, they couldn't code surreptitious trojans for the 2015 toolchain.

Re:not trusting is hard work

[Paul Jakma]

Not sure what car manifolds have to do with it - argumentum ad vehiculum.

Again, you're assuming that an old toolchain can only have old attacks. That's a flawed assumption. A modern attacker can subvert your system so that old toolchains are subverted to apply further subversions.

Are there practical steps we can take to raise the bar and make such attacks much harder to execute. Sure. Can we guarantee our system is free of such subversions, without either trusting others to some degree or building the system entirely ourselves: no we can't. Which was Thompson's point.

explain how you rewrite the laws of physics

[raymorris]

> A modern attacker can subvert your system so that old toolchains are subverted to apply further subversions.

Explain please, how you imagine the silver in a pressed Borland Turbo CD or the DOS CD it runs on, is going to get new malware added to 20 years after it was pressed.

The stock Borland Turbo and DOS disks are read-only. That means they can't be changed. I'm not sure what part of read-only you don't understand.

Re:explain how you rewrite the laws of physics

[Paul Jakma]

The system is subverted, e.g. command.com has been modified, so that when Borland Turbo is loaded into memory it too is subverted. Alternatively, DOS 22h is replaced with a version that checks every disk write to see if it is the beginning of a DOS executable, and if so, subverts it. Alternatively, ... etc.

There are surely many ways. Otherwise, you are arguing that DOS is not vulnerable to a broad range of all-powerful subversions, which is patently untrue.

trolling are really that dense?

[raymorris]

> command.com has been modified

I'm not sure if you're just trolling or if you really, truly don't know what a CD-ROM is, what read-only means.

Before iphones - I mean before the very first iphone, and before Windows 7 or 8, you couldn't download apps. Instead, apps were made out of aluminum- metal. The metal was inside of some plastic. You had to physically walk into a store to buy your apps, and you'd walk out with these metal and plastic circles. Those circles had the apps. You couldn't change them. The operating system was the same way. To update your system, you'd throw away your old"metal circle and buy a new, different one.