| 1 |
Hello Paweł, |
| 2 |
|
| 3 |
Saturday, August 9, 2014, 1:34:29 PM, you wrote: |
| 4 |
|
| 5 |
> Possibly relevant article would be |
| 6 |
> <http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html> |
| 7 |
|
| 8 |
>>> The number of bugs is the same. It's more difficult to hack into 1996 system |
| 9 |
>>> than in 2012. |
| 10 |
|
| 11 |
> Do you have any evidence to back that claim? There are tons of known |
| 12 |
> vulnerabilities in '96-era software, and automated exploits for them. |
| 13 |
|
| 14 |
> By the way, I can see a point in your thread. Our updates and package |
| 15 |
> manager could be improved. They have improved greatly in the last few |
| 16 |
> years. I think I can safely say we welcome further contributions of |
| 17 |
> patches, packaging and testing effort, especially helping automate many |
| 18 |
> of these tasks. |
| 19 |
|
| 20 |
In my experience - hacking into 96 system with a 0 door is much harder |
| 21 |
than in 2014. In most cases unless you're an expert on 96 software which |
| 22 |
is difficult nowadays due to human memory. To really break in you need to |
| 23 |
reproduce server environment as close as possible or/and have a clear |
| 24 |
understanding how this particular software works. Try to assemble a |
| 25 |
96 system on modern hardware or assemble it as they were back in 96, |
| 26 |
not all sources are online any longer, that is a hard job. 2014 systems |
| 27 |
are much easier to assemble and get a peek to the sources is a trifle. |
| 28 |
|
| 29 |
As Linux software is open-source it's often easier to break in Linux |
| 30 |
than in Windows systems. The open source is only theoretically safer. |
| 31 |
Many belive that because the code is open - it's reviewed and checked |
| 32 |
and the number of critical bugs is low. But the reality is that there |
| 33 |
is usually no time to review code. Many modern software is very complex |
| 34 |
with millions lines and it's not realistic to check or |
| 35 |
understand how it works before you use it in your project. Tell me |
| 36 |
how many libraries that you use right now are reviewed by you personally? |
| 37 |
Not many. And that is a door that is NEVER going to be closed. There are |
| 38 |
bugs, rest assured, if you pull any soft right now and spend time |
| 39 |
you will find them. If you have an expertise on cross platforms - you |
| 40 |
will find even more as developers used to focus on one platform the birth |
| 41 |
platform. |
| 42 |
|
| 43 |
If you compare the number of bugs you find in 1996 software and in 2014 |
| 44 |
- the numbers would approximately be the same. |
| 45 |
|
| 46 |
Usually 1996 system is patched or protected against known issues and you |
| 47 |
have to deal with "unknown" which in case of 1996 is much harder. |
| 48 |
|
| 49 |
Another weak link with open source is software developers. Many of them |
| 50 |
spend a lot of time on their software not always getting a fair monetary |
| 51 |
reward. So if you a very shrewd and have resources - you go to developers |
| 52 |
and offer them money to introduce a subtle bug into the main tree. After |
| 53 |
the software is adopted then you have open doors in EVERY "updated" |
| 54 |
linux on the planet. |
| 55 |
|
| 56 |
Personally I belive Heart Bleed bug is one of such. You can never proof |
| 57 |
if the bug is artificial or not - how? |
| 58 |
|
| 59 |
The same true for Microsoft soft. You can basically go to a ntkernel |
| 60 |
developer offer him 500 000$ if have them and he would add a bug and |
| 61 |
explain you how to use it and you're everywhere :-) but this is usually |
| 62 |
the government's methods. They used to keep them secret. |
| 63 |
|
| 64 |
-- |
| 65 |
Best regards, |
| 66 |
Igor mailto:lanthruster@×××××.com |
Archives