At 9:46 PM +0200 7/20/06, Florian Weimer wrote:
> * Pascal Meunier:
>
>> But it's true for stupid bugs like buffer overflows and format string
>> vulnerabilities, in which we're still swimming, and the proof is the fact
>> that those aren't possible in some languages.
>
> Could you name a few such
At 9:11 PM +0200 7/20/06, Florian Weimer wrote:
> Most things in this list are implemented in C or C++, but the problems
> are at such a high level that it's unlikely that a different choice of
> wildly different programming language would make a huge difference.
> If you look at lower-level bugs,
* Pascal Meunier:
> But it's true for stupid bugs like buffer overflows and format string
> vulnerabilities, in which we're still swimming, and the proof is the fact
> that those aren't possible in some languages.
Could you name a few such language implementations? 8-)
In most cases, the compone
On 7/20/06 3:11 PM, "Florian Weimer" <[EMAIL PROTECTED]> wrote:
> * Pascal Meunier:
>
>> Also, writing it twice with different languages, especially at different
>> levels of abstraction, makes it less likely that the same bugs will appear
>> in both.
>
> Algorithmic issues such as denial of
On 7/20/06 3:46 PM, "Florian Weimer" <[EMAIL PROTECTED]> wrote:
> * Pascal Meunier:
>
>> But it's true for stupid bugs like buffer overflows and format string
>> vulnerabilities, in which we're still swimming, and the proof is the fact
>> that those aren't possible in some languages.
>
> Coul
| Absolute security is a myth. As is designing absolutely secure
| software.
| >>
| >>> I have high hopes in formal methods.
| >>
| >> All formal methods do is push bugs around...
| >
| > But people are forced to spend more time with the code, which
| > generally helps them (in partic
On 7/20/06 1:57 PM, "Gary McGraw" <[EMAIL PROTECTED]> wrote:
> I'm afraid that's not true. John Knight has a famous paper that shows that
> design/requirements bugs persist in n-version programming paradigms. I'll let
> the interested people google that one up for themselves.
>
> gem
But it'
* Pascal Meunier:
> Also, writing it twice with different languages, especially at different
> levels of abstraction, makes it less likely that the same bugs will appear
> in both.
Algorithmic issues such as denial of service attacks through
unbalanced binary trees or hash table collisions are pr
Gary McGraw wrote:
> And don't forget about the compiler you will no doubt have to use. Do you
> trust that?
>
> You might want to read Thompson's classic "reflections on trusting trust".
> www.acm.org/classics/sep95
>
> All your compilers are belong to us.
While that is always a good read,
I've been asked to review some tcl code that works on data from untrusted
sources. I've dabbled in tcl a couple of times, but don't consider myself any
sort of expert and I'm looking for a bit of automated help.
Anyone know of a tool like rats, its4, or codeassure that works on tcl source,
or
I'm afraid that's not true. John Knight has a famous paper that shows that
design/requirements bugs persist in n-version programming paradigms. I'll let
the interested people google that one up for themselves.
gem
company www.cigital.com.
podcast www.cigital.com/silverbullet
book www.swsec.co
On 7/20/06 11:58 AM, "Florian Weimer" <[EMAIL PROTECTED]> wrote:
> * der Mouse:
>
Absolute security is a myth. As is designing absolutely secure
software.
>>
>>> I have high hopes in formal methods.
>>
>> All formal methods do is push bugs around. Basically, you end up
>> writing
Hi guys!
A few days ago, following the announcements by Dan from Websense and then
HD, I wrote a post covering what they have done and what the future may
gold for Google hacking for security purposes.
http://blogs.securiteam.com/index.php/archives/513
Today a guy posted a blog on using the file
Dana,
Regarding your remarks about writing perfectly secure code...
well put.
And your remarks about Ross Anderson...
> Ross Anderson once said that secure software engineering is about
> building systems to remain dependable in the face of malice, error,
> or mischance. I think he has something
* Brian A. Shea:
> My slogan:
>
> Unsecured Applications = Unsecured Business
Which is completely acceptable if you and your business partners are
aware of the risk level at which your are running your company.
Secure software costs more, requires more user training, and fails in
hard-to-underst
* der Mouse:
>>> Absolute security is a myth. As is designing absolutely secure
>>> software.
>
>> I have high hopes in formal methods.
>
> All formal methods do is push bugs around. Basically, you end up
> writing in a higher-level language (the spec you are formally verifying
> the program mee
And don't forget about the compiler you will no doubt have to use. Do you
trust that?
You might want to read Thompson's classic "reflections on trusting trust".
www.acm.org/classics/sep95
All your compilers are belong to us.
gem
company www.cigital.com
podcast www.cigital.com/silverbullet
b
> yeah.
> but none of this changes the fact that it IS possible to write
completely secure code.
> -- mic
And it IS possible that a man will walk on Mars someday. But its not
practical or realistic in the society we live in today. I'm sorry mic,
but I have to disagree with you here.
It is EXTREME
On 7/20/06, Andrew van der Stock <[EMAIL PROTECTED]> wrote:
> Actually, it is a myth.
>
> For every non-trivial system, there are business pressures on
> resourcing, deadlines, and acceptable quality (pick any two). Once a
> business has set their taste for risk, it makes no sense to spend say
> $1
19 matches
Mail list logo
