full-disclosure - Coding securely, was Linux (in)security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <003701c39e1f$10e231e0$7b00a8c0@BillDell>
From: full-disclosure at royds.net (Bill Royds)
Subject: Coding securely, was Linux (in)security 

Steve is not asking that a language be less than Turing-complete, only that
insecure operations are difficult and that one would need to work hard to
write insecure code.  One could still implement anything if needed but it
would need to be explicit.
   This can be achieved in many ways by languages that do bounds checking on
strings and arrays, do not allow pointers to arbitrary data but force all
pointers to use descriptors (the VAX calling convention had all argument
lists as descriptors  forcing type safety on function calls as much as
possibile in hardware). Some of these techniques are what the secure Linuxes
use to prevent manipulation of calling stacks.
  Unfortunately other considerations than security seem to dominate
tradeoffs. Having hardware checks of array bounds adds some overhead to
array addressing, for example, so most programmers schooled in the
efficiency is first discipline rebel at such architectures.

----- Original Message ----- 
From: <Valdis.Kletnieks@...edu>
To: "Steve Wray" <steve.wray@...adise.net.nz>
Cc: "'Paul Schmehl'" <pauls@...allas.edu>;
<full-disclosure@...ts.netsys.com>
Sent: Tuesday, October 28, 2003 2:46 PM
Subject: Re: [Full-Disclosure] Coding securely, was Linux (in)security

On Tue, 28 Oct 2003 17:44:55 +1300, Steve Wray <steve.wray@...adise.net.nz>
said:

> Is it beyond all possibility that there exist languages in which
> the very reverse is true? ie Languages in which one would have to
> reimplement data types and so forth in order to be able to write
> insecure code?
>
> Can there exist such a language?? I reckon so.

No.

All programming languages that are Turing-complete (basically, anything that
has a conditional loop) are prone to the Turing Halting Problem.

In other words, you can't prevent DoS-via-infinite-loop based on input.