null

TalkBack 1 of 14:

Next »

• Thread View
• Flat View

I see ...

you have read Schneiers work ... everyone should.
(And why not also Kevin Mitnik )

It is the well known Fort Knox paradigm ...

Everyone knows where the Gold is ...
Wouldn't it be Wiser to simply hide the Gold in smaller and spread vaults?
Simple answer: No.

At that same exchange I indeed was surprised to know that OSS was not accepted at the DoD!
The only single OS's that can guarantee them total safety is left out??
And even if they wanted actually their proprietary stuff they could simply pick up a Linux version, modified for themselves some critical network code or API and them simply up-date and patch from the rest of the OS as bugs are been always found ...
What could be safer for them?
They can Look at the code, that is the ultimate guarantee.
They can have a team of people dedicated to code revision.
Every time they get an up-date they can certify the code safety for their use, and about the exploits they can be sure they have the worlds biggest community out there concerned about safety checking for the entire OSS "safety" and security.
Nothing is hidden!
They can even modify their code in order to obtain variabily from outside.
So they can have both a different code on vital parts that no one knows And ... fully revised fresh temporarily bug-free code!
Also they can guarantee that their code does not have Malicious intent as all the source is visible.

Those that deal with this subject as a hobby for many years know that the worst enemy of an attack like a simple exploit from for example a so called "Buffer Overflow" (actually there are many types of Buffer overflows) knows that the worst possible thing to transform a bug into an exploit is indeed variation.
To take advantage of Buffer overflows assembler code as to be written so specific for that exact problem that the simplest change in a memory addressing could render the exploit useless.

I recommend for those with interest and some patience a book from Syngress, about buffer overflows and exploits. (sorry for the marketing, Buffer Overflow attaks, detect, exploit, prevent, James C. Foster, Vitali Osipov, Nish Bhalla, Niels Heinen )
Some years ago I was a great fan of exploits and Bug hunting, I collected some exploit code, now I simply have no time now.
I left the subject.

Note: (Murph do not forget to put a title on your articles ... )

Regards,
Pedro

Posted by: p_msac@...   Posted on: 05/04/07 You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

SponsoredWhite Papers, Webcasts, and Downloads

• Virtualization: Architectural Considerations And Other Evaluation Criteria VMware Of the many approaches to x86 systems virtualization available in the ... Download Now
• Designing a Balanced Architecture With Oracle RAC and VERITAS Software for Linux Dell Introducing Oracle RAC into an IT infrastructure and using Linux as the ... Download Now
• Why Isn't Server Virtualization Saving Us More? A Few Small Changes May Dramatically Increase Your Efficiency VMware Companies have rapidly adopted server virtualization over the past few ... Download Now