[OT] Re: [gentoo-dev] minimalistic emerge

[Tom Wijsman]

On Sat, 9 Aug 2014 19:25:56 +0400
Igor <lanthruster@×××××.com> wrote:

> In my experience - hacking into 96 system with a 0 door is much
> harder than in 2014. In most cases unless you're an expert on 96
> software which is difficult nowadays due to human memory.

Why does one need to be an expert?

How about known and/or implemented exploits?

> To really break in you need to reproduce server environment as close
> as possible or/and have a clear understanding how this particular
> software works. Try to assemble a 96 system on modern hardware or
> assemble it as they were back in 96, not all sources are online any
> longer, that is a hard job. 2014 systems are much easier to assemble
> and get a peek to the sources is a trifle.

Why reproduce the environment?

Is the sources' availability the only factor?

> As Linux software is open-source it's often easier to break in Linux
> than in Windows systems. The open source is only theoretically safer.
> Many belive that because the code is open - it's reviewed and checked
> and the number of critical bugs is low. But the reality is that there
> is usually no time to review code. Many modern software is very
> complex with millions lines and it's not realistic to check or
> understand how it works before you use it in your project. Tell me
> how many libraries that you use right now are reviewed by you
> personally? Not many. And that is a door that is NEVER going to be
> closed. There are bugs, rest assured, if you pull any soft right now
> and spend time you will find them. If you have an expertise on cross
> platforms - you will find even more as developers used to focus on
> one platform the birth platform.

Can you back up that open source is theoretically safer / harder / ...?

It depends on how you look at the source code and binaries; having
either doesn't necessarily make it easier or harder to accomplish,
especially if you want to find run-time behavior to exploit.

You could scan through the source code looking for known errors or so;
however, the same is possible to do with the machine code. Both can be
done manually or automatically; whether it gets tedious to find, depends
on what it is exactly that you are trying to find and how you find it.

> If you compare the number of bugs you find in 1996 software and in
> 2014
> - the numbers would approximately be the same.

That reads like a wild guess due to too much assumptions / conditionals.

> Usually 1996 system is patched or protected against known issues and
> you have to deal with "unknown" which in case of 1996 is much harder.

This also reads like a wild guess; words ending in -ly like "usually"
indicate that you're not sure about it and how much of it really is as
such, a more believable statement would read like "...% of the systems
in 1996 are ... [reference to research]".

> Another weak link with open source is software developers. Many of
> them spend a lot of time on their software not always getting a fair
> monetary reward. So if you a very shrewd and have resources - you go
> to developers and offer them money to introduce a subtle bug into the
> main tree. After the software is adopted then you have open doors in
> EVERY "updated" linux on the planet.
>
> Personally I belive Heart Bleed bug is one of such. You can never
> proof if the bug is artificial or not - how?
>
> The same true for Microsoft soft. You can basically go to a ntkernel
> developer offer him 500 000$ if have them and he would add a bug and
> explain you how to use it and you're everywhere :-) but this is
> usually the government's methods. They used to keep them secret.

Have you considered steady high incomes and the aftermath?

With a steady high income and a high level job as Microsoft kernel
developer, 500 000$ and the aftermath of consequences loses traction.

You might be able to convince that single kernel developer; however,
that developer still has to slip this by the rest of the kernel
development team as well as quality assurance processes and measures.

Getting by the static and dynamic analyzers as well as other run-time
measures they have to their availability for awareness is harder than
without it; apart from it, there's are also human code reviews and QA.

The story gets somewhat different when people don't end up using them,
or not spend an equivalent effort; like for example with Heart Bleed.

Think about some random unrelated pieces of open source libraries; did
that get run through analyzers and include run-time measures, have code
reviews like kernels would have and extended QA procedures?

https://i.imgflip.com/b3mx0.jpg

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D