Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: gentoo-dev@l.g.o
Subject: [OT] Re: [gentoo-dev] minimalistic emerge
Date: Wed, 13 Aug 2014 07:54:48
In Reply to: Re: [gentoo-dev] minimalistic emerge by Igor
1 On Sat, 9 Aug 2014 19:25:56 +0400
2 Igor <lanthruster@×××××.com> wrote:
4 > In my experience - hacking into 96 system with a 0 door is much
5 > harder than in 2014. In most cases unless you're an expert on 96
6 > software which is difficult nowadays due to human memory.
8 Why does one need to be an expert?
10 How about known and/or implemented exploits?
12 > To really break in you need to reproduce server environment as close
13 > as possible or/and have a clear understanding how this particular
14 > software works. Try to assemble a 96 system on modern hardware or
15 > assemble it as they were back in 96, not all sources are online any
16 > longer, that is a hard job. 2014 systems are much easier to assemble
17 > and get a peek to the sources is a trifle.
19 Why reproduce the environment?
21 Is the sources' availability the only factor?
23 > As Linux software is open-source it's often easier to break in Linux
24 > than in Windows systems. The open source is only theoretically safer.
25 > Many belive that because the code is open - it's reviewed and checked
26 > and the number of critical bugs is low. But the reality is that there
27 > is usually no time to review code. Many modern software is very
28 > complex with millions lines and it's not realistic to check or
29 > understand how it works before you use it in your project. Tell me
30 > how many libraries that you use right now are reviewed by you
31 > personally? Not many. And that is a door that is NEVER going to be
32 > closed. There are bugs, rest assured, if you pull any soft right now
33 > and spend time you will find them. If you have an expertise on cross
34 > platforms - you will find even more as developers used to focus on
35 > one platform the birth platform.
37 Can you back up that open source is theoretically safer / harder / ...?
39 It depends on how you look at the source code and binaries; having
40 either doesn't necessarily make it easier or harder to accomplish,
41 especially if you want to find run-time behavior to exploit.
43 You could scan through the source code looking for known errors or so;
44 however, the same is possible to do with the machine code. Both can be
45 done manually or automatically; whether it gets tedious to find, depends
46 on what it is exactly that you are trying to find and how you find it.
48 > If you compare the number of bugs you find in 1996 software and in
49 > 2014
50 > - the numbers would approximately be the same.
52 That reads like a wild guess due to too much assumptions / conditionals.
54 > Usually 1996 system is patched or protected against known issues and
55 > you have to deal with "unknown" which in case of 1996 is much harder.
57 This also reads like a wild guess; words ending in -ly like "usually"
58 indicate that you're not sure about it and how much of it really is as
59 such, a more believable statement would read like "...% of the systems
60 in 1996 are ... [reference to research]".
62 > Another weak link with open source is software developers. Many of
63 > them spend a lot of time on their software not always getting a fair
64 > monetary reward. So if you a very shrewd and have resources - you go
65 > to developers and offer them money to introduce a subtle bug into the
66 > main tree. After the software is adopted then you have open doors in
67 > EVERY "updated" linux on the planet.
68 >
69 > Personally I belive Heart Bleed bug is one of such. You can never
70 > proof if the bug is artificial or not - how?
71 >
72 > The same true for Microsoft soft. You can basically go to a ntkernel
73 > developer offer him 500 000$ if have them and he would add a bug and
74 > explain you how to use it and you're everywhere :-) but this is
75 > usually the government's methods. They used to keep them secret.
77 Have you considered steady high incomes and the aftermath?
79 With a steady high income and a high level job as Microsoft kernel
80 developer, 500 000$ and the aftermath of consequences loses traction.
82 You might be able to convince that single kernel developer; however,
83 that developer still has to slip this by the rest of the kernel
84 development team as well as quality assurance processes and measures.
86 Getting by the static and dynamic analyzers as well as other run-time
87 measures they have to their availability for awareness is harder than
88 without it; apart from it, there's are also human code reviews and QA.
90 The story gets somewhat different when people don't end up using them,
91 or not spend an equivalent effort; like for example with Heart Bleed.
93 Think about some random unrelated pieces of open source libraries; did
94 that get run through analyzers and include run-time measures, have code
95 reviews like kernels would have and extended QA procedures?
99 --
100 With kind regards,
102 Tom Wijsman (TomWij)
103 Gentoo Developer
105 E-mail address : TomWij@g.o
106 GPG Public Key : 6D34E57D
107 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D


File name MIME type
signature.asc application/pgp-signature