|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385243 is a reply to message #385167] |
Sat, 20 July 2019 15:18   |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
> Rust in peace: Memory bugs in C and C++ code cause security issues so
> Microsoft is considering alternatives once again
> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>
> The majority of vulnerabilities fixed and with a CVE assigned are caused
> by developers inadvertently inserting memory corruption bugs into their
> C and C++ code. As Microsoft increases its code base and uses more Open
> Source Software in its code, this problem isn't getting better, it's
> getting worse.
Rust never sleeps... that would perhaps have made a better reference.
I think that a technical solution to buffer overflows, rather than just
expecting programmers to do a better job, *is* a good idea.
However, my solution would not be to use different languages, at least not
directly, although C and C++ would probably be disqualified as an indirect
result. My solution would be to use a different *operating system*, one like MTS
or OS/360, in which text files on disk - and, therefore, input-output streams in
general - looked, or were made to look, like a series of "Pascal strings",
instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
of "C strings".
That is, a stream of text comes with the length of each line in an "out-of-band"
form, instead of with lines separated one from another by some delimiter
character "in band". Therefore the record length now has an *absolute maximum*
due to the size of the field giving the length of the current record, with no
chance of a buffer overflow if the delimiter character doesn't happen to turn up
in time.
Of course, this is just my baby duck syndrome talking...
John Savard
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385244 is a reply to message #385243] |
Sat, 20 July 2019 15:50 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 20 Jul 2019 12:18:31 -0700 (PDT)
Quadibloc <jsavard@ecn.ab.ca> wrote:
> However, my solution would not be to use different languages, at least
> not directly, although C and C++ would probably be disqualified as an
> indirect result. My solution would be to use a different *operating
> system*, one like MTS or OS/360, in which text files on disk - and,
> therefore, input-output streams in general - looked, or were made to
> look, like a series of "Pascal strings", instead of, as in Unix, DOS,
> MacOS, and even on the Commodore 64, like a series of "C strings".
No they don't, they look like (and are) an array of bytes.
> That is, a stream of text comes with the length of each line in an
> "out-of-band" form, instead of with lines separated one from another by
> some delimiter character "in band". Therefore the record length now has
> an *absolute maximum* due to the size of the field giving the length of
> the current record, with no chance of a buffer overflow if the delimiter
> character doesn't happen to turn up in time.
Nothing to stop you using a storage/transfer format like this,
various variations of tag-length-value have been used for decades. No need
for another OS just a library.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385246 is a reply to message #385244] |
Sat, 20 July 2019 16:35 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Ahem A Rivet's Shot <steveo@eircom.net> writes:
> Nothing to stop you using a storage/transfer format like this,
> various variations of tag-length-value have been used for decades. No need
> for another OS just a library.
re:
http://www.garlic.com/~lynn/2019d.html#18 Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again
unix&c convention had implicit record length based on character in the
stream
os/360 had explicit length convention for buffers and variable length
records, language libraries always checked length and most assembler
code had convention to always check length (from length specification
for variable length records and declared length for fixed length
records)
multics originally all implemented in PLI (although some later recoded
in assembler for performance) ... with similar conventions. Old thread
referencing review Air Force Multics security study, 30yrs later
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation
2.2 Security as Standard Product Feature
2.3 No Buffer Overflows
2.4 Minimizing Complexity
http://www.acsac.org/2002/papers/classic-multics.pdf
from the intro in the above:
This Research Report consists of two invited papers for the Classic
Papers section of the 18 th Annual Computer Security Applications
Conference (ACSAC) to be held 9-13 December 2002 in Las Vegas, NV. The
papers will be available on the web after the conference at
http://www.acsac.org/">http://www.acsac.org/
The first paper, Thirty Years Later: Lessons from the Multics Security
Evaluation, is a commentary on the second paper, discussing the
implications of the second paper's results on contemporary computer
security issues. Copyright will be transferred on the first paper.
The second paper, Multics Security Evaluation: Vulnerability Analysis
is a reprint of a US Air Force report, first published in 1974. It is
a government document, approved for public release, distribution
unlimited, and is not subject to copyright. This reprint does not
include the original computer listings. They can be found at
http://csrc.nist.gov/publications/history/karg74.pdf
.... snip ...
NIST since moved to (although above redirects)
https://csrc.nist.gov/csrc/media/publications/conference-pap er/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/e arly-cs-papers/karg74.pdf
other (old) pontificating on the subject in this thread
http://www.garlic.com/~lynn/2004q.html#3 Buffer overruns
related archived posts
http://www.garlic.com/~lynn/subintegrity.html#overflow
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385247 is a reply to message #385243] |
Sat, 20 July 2019 16:43 |
|
|
Originally posted by: Carlos E.R.
On 20/07/2019 21.18, Quadibloc wrote:
> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>> Microsoft is considering alternatives once again
>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>
>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>> by developers inadvertently inserting memory corruption bugs into their
>> C and C++ code. As Microsoft increases its code base and uses more Open
>> Source Software in its code, this problem isn't getting better, it's
>> getting worse.
>
> Rust never sleeps... that would perhaps have made a better reference.
>
> I think that a technical solution to buffer overflows, rather than just
> expecting programmers to do a better job, *is* a good idea.
>
> However, my solution would not be to use different languages, at least not
> directly, although C and C++ would probably be disqualified as an indirect
> result. My solution would be to use a different *operating system*, one like MTS
> or OS/360, in which text files on disk - and, therefore, input-output streams in
> general - looked, or were made to look, like a series of "Pascal strings",
> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
> of "C strings".
>
> That is, a stream of text comes with the length of each line in an "out-of-band"
> form, instead of with lines separated one from another by some delimiter
> character "in band". Therefore the record length now has an *absolute maximum*
> due to the size of the field giving the length of the current record, with no
> chance of a buffer overflow if the delimiter character doesn't happen to turn up
> in time.
This strategy has still a problem: the size of the "string" may not be
the size of the storage area where it is stored. Like you can store an
89 char string in a 255 byte string var. Something else has to know that
you can not store a 300 char string there, and check for it.
For example, the pascal compiler (the Borland variant at least) knows
the size of variables, arrays as such, and can prevent an out of bounds
access (unless the programmer disables the run time checks because they
make the program slower, which many do), and as long as the variables
are not dynamic, assigned on the heap and accessed by pointers, it
works. Crashing programs on those accesses.
> Of course, this is just my baby duck syndrome talking...
>
> John Savard
>
--
Cheers, Carlos.
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385248 is a reply to message #385243] |
Sat, 20 July 2019 16:59 |
|
|
Originally posted by: antispam
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>> Microsoft is considering alternatives once again
>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>
>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>> by developers inadvertently inserting memory corruption bugs into their
>> C and C++ code. As Microsoft increases its code base and uses more Open
>> Source Software in its code, this problem isn't getting better, it's
>> getting worse.
>
> Rust never sleeps... that would perhaps have made a better reference.
>
> I think that a technical solution to buffer overflows, rather than just
> expecting programmers to do a better job, *is* a good idea.
>
> However, my solution would not be to use different languages, at least not
> directly, although C and C++ would probably be disqualified as an indirect
> result. My solution would be to use a different *operating system*, one like MTS
> or OS/360, in which text files on disk - and, therefore, input-output streams in
> general - looked, or were made to look, like a series of "Pascal strings",
> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
> of "C strings".
>
> That is, a stream of text comes with the length of each line in an "out-of-band"
> form, instead of with lines separated one from another by some delimiter
> character "in band". Therefore the record length now has an *absolute maximum*
> due to the size of the field giving the length of the current record, with no
> chance of a buffer overflow if the delimiter character doesn't happen to turn up
> in time.
Sorry, OS solve _nothing_, main danger is due to data coming from
network, such data naturaly has structure of effectively unbounded
stream and OS can not change that. Also, now problems _directly_
with data coming from outside are rare. Main problem is that
data travels internally in program and appears in a priori
unexpected places. Problem is mainly due to C (C++ without
C compatiblity would be OK). And solution is well-known
for long time, it was invented in Pascal (and Java uses
essentially the same solution as Pascal). More technically,
in C given a pointer compiler does not know size of
correcponding buffer. In Pascal given a pointer compiler
can compute size of buffer and automatically inserts
check so that each access is in bounds. In seventies
automatic bounds checking was rejected as too expensive.
Modern tests show that average cost is about 10% (less than
say Spectre mitigation). Some folks may still consider
this 10% as "too expensive", but IMO most people would
gladly accept such performance loss for freedom of
buffer overflows...
--
Waldek Hebisch
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385249 is a reply to message #385243] |
Sat, 20 July 2019 17:22 |
|
|
Originally posted by: J. Clarke
On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
<jsavard@ecn.ab.ca> wrote:
> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>> Microsoft is considering alternatives once again
>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>
>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>> by developers inadvertently inserting memory corruption bugs into their
>> C and C++ code. As Microsoft increases its code base and uses more Open
>> Source Software in its code, this problem isn't getting better, it's
>> getting worse.
>
> Rust never sleeps... that would perhaps have made a better reference.
>
> I think that a technical solution to buffer overflows, rather than just
> expecting programmers to do a better job, *is* a good idea.
>
> However, my solution would not be to use different languages, at least not
> directly, although C and C++ would probably be disqualified as an indirect
> result. My solution would be to use a different *operating system*, one like MTS
> or OS/360, in which text files on disk - and, therefore, input-output streams in
> general - looked, or were made to look, like a series of "Pascal strings",
> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
> of "C strings".
>
> That is, a stream of text comes with the length of each line in an "out-of-band"
> form, instead of with lines separated one from another by some delimiter
> character "in band". Therefore the record length now has an *absolute maximum*
> due to the size of the field giving the length of the current record, with no
> chance of a buffer overflow if the delimiter character doesn't happen to turn up
> in time.
>
> Of course, this is just my baby duck syndrome talking...
In MVS, records on DASD or tape are fixed length. C works fine. But
one can still create overflows.
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385251 is a reply to message #385247] |
Sat, 20 July 2019 19:31 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Carlos E.R. <robin_listas@es.invalid> wrote:
> On 20/07/2019 21.18, Quadibloc wrote:
>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>> Microsoft is considering alternatives once again
>>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>
>>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>> by developers inadvertently inserting memory corruption bugs into their
>>> C and C++ code. As Microsoft increases its code base and uses more Open
>>> Source Software in its code, this problem isn't getting better, it's
>>> getting worse.
>>
>> Rust never sleeps... that would perhaps have made a better reference.
>>
>> I think that a technical solution to buffer overflows, rather than just
>> expecting programmers to do a better job, *is* a good idea.
>>
>> However, my solution would not be to use different languages, at least not
>> directly, although C and C++ would probably be disqualified as an indirect
>> result. My solution would be to use a different *operating system*, one like MTS
>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>> general - looked, or were made to look, like a series of "Pascal strings",
>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>> of "C strings".
>>
>> That is, a stream of text comes with the length of each line in an "out-of-band"
>> form, instead of with lines separated one from another by some delimiter
>> character "in band". Therefore the record length now has an *absolute maximum*
>> due to the size of the field giving the length of the current record, with no
>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>> in time.
>
> This strategy has still a problem: the size of the "string" may not be
> the size of the storage area where it is stored. Like you can store an
> 89 char string in a 255 byte string var. Something else has to know that
> you can not store a 300 char string there, and check for it.
>
> For example, the pascal compiler (the Borland variant at least) knows
> the size of variables, arrays as such, and can prevent an out of bounds
> access (unless the programmer disables the run time checks because they
> make the program slower, which many do), and as long as the variables
> are not dynamic, assigned on the heap and accessed by pointers, it
> works. Crashing programs on those accesses.
PL/I checks in all those cases. Newer versions have added some C-isms that
bypass the checks, but the standard language is safe.
--
Pete
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385252 is a reply to message #385248] |
Sat, 20 July 2019 19:31 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<antispam@math.uni.wroc.pl> wrote:
> Quadibloc <jsavard@ecn.ab.ca> wrote:
>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>> Microsoft is considering alternatives once again
>>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>
>>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>> by developers inadvertently inserting memory corruption bugs into their
>>> C and C++ code. As Microsoft increases its code base and uses more Open
>>> Source Software in its code, this problem isn't getting better, it's
>>> getting worse.
>>
>> Rust never sleeps... that would perhaps have made a better reference.
>>
>> I think that a technical solution to buffer overflows, rather than just
>> expecting programmers to do a better job, *is* a good idea.
>>
>> However, my solution would not be to use different languages, at least not
>> directly, although C and C++ would probably be disqualified as an indirect
>> result. My solution would be to use a different *operating system*, one like MTS
>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>> general - looked, or were made to look, like a series of "Pascal strings",
>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>> of "C strings".
>>
>> That is, a stream of text comes with the length of each line in an "out-of-band"
>> form, instead of with lines separated one from another by some delimiter
>> character "in band". Therefore the record length now has an *absolute maximum*
>> due to the size of the field giving the length of the current record, with no
>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>> in time.
>
> Sorry, OS solve _nothing_, main danger is due to data coming from
> network, such data naturaly has structure of effectively unbounded
> stream and OS can not change that. Also, now problems _directly_
> with data coming from outside are rare. Main problem is that
> data travels internally in program and appears in a priori
> unexpected places. Problem is mainly due to C (C++ without
> C compatiblity would be OK). And solution is well-known
> for long time, it was invented in Pascal (and Java uses
> essentially the same solution as Pascal). More technically,
> in C given a pointer compiler does not know size of
> correcponding buffer. In Pascal given a pointer compiler
> can compute size of buffer and automatically inserts
> check so that each access is in bounds. In seventies
> automatic bounds checking was rejected as too expensive.
> Modern tests show that average cost is about 10% (less than
> say Spectre mitigation). Some folks may still consider
> this 10% as "too expensive", but IMO most people would
> gladly accept such performance loss for freedom of
> buffer overflows...
>
If the compiled code doesn’t check, the programmer has to check, unless, of
course “the string length can never exceed x.” The overhead is the same in
either case, or maybe more to do the checking in the application.
--
Pete
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385253 is a reply to message #385249] |
Sat, 20 July 2019 19:31 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
> <jsavard@ecn.ab.ca> wrote:
>
>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>> Microsoft is considering alternatives once again
>>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>
>>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>> by developers inadvertently inserting memory corruption bugs into their
>>> C and C++ code. As Microsoft increases its code base and uses more Open
>>> Source Software in its code, this problem isn't getting better, it's
>>> getting worse.
>>
>> Rust never sleeps... that would perhaps have made a better reference.
>>
>> I think that a technical solution to buffer overflows, rather than just
>> expecting programmers to do a better job, *is* a good idea.
>>
>> However, my solution would not be to use different languages, at least not
>> directly, although C and C++ would probably be disqualified as an indirect
>> result. My solution would be to use a different *operating system*, one like MTS
>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>> general - looked, or were made to look, like a series of "Pascal strings",
>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>> of "C strings".
>>
>> That is, a stream of text comes with the length of each line in an "out-of-band"
>> form, instead of with lines separated one from another by some delimiter
>> character "in band". Therefore the record length now has an *absolute maximum*
>> due to the size of the field giving the length of the current record, with no
>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>> in time.
>>
>> Of course, this is just my baby duck syndrome talking...
>
> In MVS, records on DASD or tape are fixed length.
Not true, you have variable and “undefined” records, as well as spanned.
> C works fine. But
> one can still create overflows.
>
--
Pete
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385258 is a reply to message #385253] |
Sat, 20 July 2019 20:27 |
|
|
Originally posted by: J. Clarke
On Sat, 20 Jul 2019 16:31:08 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> J. Clarke <jclarke.873638@gmail.com> wrote:
>> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
>> <jsavard@ecn.ab.ca> wrote:
>>
>>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>>> Microsoft is considering alternatives once again
>>>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>>
>>>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>>> by developers inadvertently inserting memory corruption bugs into their
>>>> C and C++ code. As Microsoft increases its code base and uses more Open
>>>> Source Software in its code, this problem isn't getting better, it's
>>>> getting worse.
>>>
>>> Rust never sleeps... that would perhaps have made a better reference.
>>>
>>> I think that a technical solution to buffer overflows, rather than just
>>> expecting programmers to do a better job, *is* a good idea.
>>>
>>> However, my solution would not be to use different languages, at least not
>>> directly, although C and C++ would probably be disqualified as an indirect
>>> result. My solution would be to use a different *operating system*, one like MTS
>>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>>> general - looked, or were made to look, like a series of "Pascal strings",
>>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>>> of "C strings".
>>>
>>> That is, a stream of text comes with the length of each line in an "out-of-band"
>>> form, instead of with lines separated one from another by some delimiter
>>> character "in band". Therefore the record length now has an *absolute maximum*
>>> due to the size of the field giving the length of the current record, with no
>>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>>> in time.
>>>
>>> Of course, this is just my baby duck syndrome talking...
>>
>> In MVS, records on DASD or tape are fixed length.
>
> Not true, you have variable and undefined records, as well as spanned.
A "variable length" record requires that the length be known before
the record is written.
A "spanned" record just spans across multiple fixed length records.
You never run into the situation "read until a special character is
encountered".
>
>> C works fine. But
>> one can still create overflows.
>>
|
|
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385260 is a reply to message #385247] |
Sat, 20 July 2019 21:19 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, July 20, 2019 at 2:52:08 PM UTC-6, Carlos E.R. wrote:
> This strategy has still a problem: the size of the "string" may not be
> the size of the storage area where it is stored. Like you can store an
> 89 char string in a 255 byte string var. Something else has to know that
> you can not store a 300 char string there, and check for it.
The whole idea is that there *are* no 300 char strings coming out of the input
command. One can never exist, because the file structure and the I/O protocol
are incompatible with them.
So if you have raw binary data that doesn't divide into records, you're forced
to cut it up into uniform chunks, say 80 column records.
Thus, the thing that knows you can't store a 300 char string there... was
written once in the operating system, or in the device drivers. Not by
applications programmers.
John Savard
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385261 is a reply to message #385248] |
Sat, 20 July 2019 21:23 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, July 20, 2019 at 2:59:28 PM UTC-6, anti...@math.uni.wroc.pl wrote:
> Sorry, OS solve _nothing_, main danger is due to data coming from
> network, such data naturaly has structure of effectively unbounded
> stream and OS can not change that.
The OS had *better* change that, or it won't be possible to write a program that
can access data coming from the network. The system calls for input all return
records of bounded length, and records of bounded length *only*.
In a case like this, of course, to handle the data, the program will still have
to check on the length of packets, as it builds them up from the fixed maximum
length chunks the operating system will let it have. When a programmer has to do
this, though, there is an awareness that bounds checking is needed: one is
forced to do more than just say "readlin(my_string);" in order to assemble a
packet.
John Savard
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385265 is a reply to message #385261] |
Sat, 20 July 2019 22:15 |
Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 21/07/2019 02:23, Quadibloc wrote:
> On Saturday, July 20, 2019 at 2:59:28 PM UTC-6, anti...@math.uni.wroc.pl wrote:
>
>> Sorry, OS solve _nothing_, main danger is due to data coming from
>> network, such data naturaly has structure of effectively unbounded
>> stream and OS can not change that.
>
> The OS had *better* change that, or it won't be possible to write a program that
> can access data coming from the network. The system calls for input all return
> records of bounded length, and records of bounded length *only*.
>
> In a case like this, of course, to handle the data, the program will still have
> to check on the length of packets, as it builds them up from the fixed maximum
> length chunks the operating system will let it have. When a programmer has to do
> this, though, there is an awareness that bounds checking is needed: one is
> forced to do more than just say "readlin(my_string);" in order to assemble a
> packet.
>
> John Savard
>
I would hope the function was
length = readbinary(my_string);
string length is returned as a positive integer
0 = empty string
-1 = end of file
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385266 is a reply to message #385260] |
Sat, 20 July 2019 22:20 |
|
|
Originally posted by: Carlos E.R.
On 21/07/2019 03.19, Quadibloc wrote:
> On Saturday, July 20, 2019 at 2:52:08 PM UTC-6, Carlos E.R. wrote:
>
>> This strategy has still a problem: the size of the "string" may not be
>> the size of the storage area where it is stored. Like you can store an
>> 89 char string in a 255 byte string var. Something else has to know that
>> you can not store a 300 char string there, and check for it.
>
> The whole idea is that there *are* no 300 char strings coming out of the input
> command. One can never exist, because the file structure and the I/O protocol
> are incompatible with them.
>
> So if you have raw binary data that doesn't divide into records, you're forced
> to cut it up into uniform chunks, say 80 column records.
>
> Thus, the thing that knows you can't store a 300 char string there... was
> written once in the operating system, or in the device drivers. Not by
> applications programmers.
What you say is absurd and doesn't relate to what I said.
In linux, for instance, you can have a single command line of many
thousands of chars, no matter what you say of "there *are* no 300 char
strings coming out of the input command"
--
Cheers, Carlos.
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385267 is a reply to message #385266] |
Sat, 20 July 2019 22:52 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, July 20, 2019 at 8:20:05 PM UTC-6, Carlos E.R. wrote:
> What you say is absurd and doesn't relate to what I said.
> In linux, for instance, you can have a single command line of many
> thousands of chars, no matter what you say of "there *are* no 300 char
> strings coming out of the input command"
In Linux. But you can't do that in OS/360.
Basically, try to type more than 72 characters, and your keyboard will lock up.
Really. (Depending on the terminal type, of course.)
John Savard
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385268 is a reply to message #385267] |
Sun, 21 July 2019 00:01 |
|
|
Originally posted by: J. Clarke
On Sat, 20 Jul 2019 19:52:03 -0700 (PDT), Quadibloc
<jsavard@ecn.ab.ca> wrote:
> On Saturday, July 20, 2019 at 8:20:05 PM UTC-6, Carlos E.R. wrote:
>
>> What you say is absurd and doesn't relate to what I said.
>
>> In linux, for instance, you can have a single command line of many
>> thousands of chars, no matter what you say of "there *are* no 300 char
>> strings coming out of the input command"
>
> In Linux. But you can't do that in OS/360.
>
> Basically, try to type more than 72 characters, and your keyboard will lock up.
> Really. (Depending on the terminal type, of course.)
And if you manage somehow to put more than 72 characters on an input
line, you'll get unexpected results because everything after column 72
is ignored.
If you want more than 72 columns you have to create a dataset with the
record length you need and then keying it in on a 3270 is a pain in
the butt.
|
|
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385277 is a reply to message #385259] |
Sun, 21 July 2019 04:22 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 20 Jul 2019 18:16:05 -0700 (PDT)
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Saturday, July 20, 2019 at 2:00:02 PM UTC-6, Ahem A Rivet's Shot wrote:
>
>> Nothing to stop you using a storage/transfer format like this,
>> various variations of tag-length-value have been used for decades. No
>> need for another OS just a library.
>
> The idea is to enhance security by ensuring all the applications are free
> of buffer overflows. So the OS has to be modified to *force everyone
> else* to have a storage/transfer format like that.
Which does nothing about the internals of the applications, as long
as there is pointer arithmetic there will be overflows.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385281 is a reply to message #385167] |
Sun, 21 July 2019 05:29 |
|
|
Originally posted by: Bob Eager
On Sun, 21 Jul 2019 09:14:20 +0000, Huge wrote:
> On 2019-07-20, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT)
>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>
>>> However, my solution would not be to use different languages, at least
>>> not directly, although C and C++ would probably be disqualified as an
>>> indirect result. My solution would be to use a different *operating
>>> system*, one like MTS or OS/360, in which text files on disk - and,
>>> therefore, input-output streams in general - looked, or were made to
>>> look, like a series of "Pascal strings", instead of, as in Unix, DOS,
>>> MacOS, and even on the Commodore 64, like a series of "C strings".
>>
>> No they don't, they look like (and are) an array of bytes.
>
> Not sure that "array" is the right word.
It would be on some systems. MULTICS and EMAS come to mind.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385283 is a reply to message #385167] |
Sun, 21 July 2019 07:37 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 21 Jul 2019 09:41:04 GMT
Huge <Huge@nowhere.much.invalid> wrote:
> On 2019-07-21, Bob Eager <news0073@eager.cx> wrote:
>> On Sun, 21 Jul 2019 09:14:20 +0000, Huge wrote:
>>
>>> On 2019-07-20, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT)
>>>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>>>
>>>> > instead of, as in Unix, DOS, MacOS, and even on the Commodore 64,
>>>> > like a series of "C strings".
>>>>
>>>> No they don't, they look like (and are) an array of bytes.
>>>
>>> Not sure that "array" is the right word.
>>
>> It would be on some systems. MULTICS and EMAS come to mind.
>
> Yes, but he was referring to Unix & Unix-like systems. (And he was wrong
Yes I was - unix gets its file model from MULTICS, a file is a
stream of bytes, TBF its only an array if it is seekable.
> about 'a series of "C strings"', also, since are not C strings null
That was Quadi not me.
> terminated?) Unix files are just a stream of bytes; the use of the
> word "array" implies some sort of structure, which isn't there. (And, yes,
> I am well aware that you know this, but others may not!)
The use of the word array implies addressable which real files are
but files representing devices may not be.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385284 is a reply to message #385283] |
Sun, 21 July 2019 08:15 |
|
|
Originally posted by: Bob Eager
On Sun, 21 Jul 2019 12:37:06 +0100, Ahem A Rivet's Shot wrote:
> On 21 Jul 2019 09:41:04 GMT Huge <Huge@nowhere.much.invalid> wrote:
>
>> On 2019-07-21, Bob Eager <news0073@eager.cx> wrote:
>>> On Sun, 21 Jul 2019 09:14:20 +0000, Huge wrote:
>>>
>>>> On 2019-07-20, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>> > On Sat, 20 Jul 2019 12:18:31 -0700 (PDT)
>>>> > Quadibloc <jsavard@ecn.ab.ca> wrote:
>>>> >
>>>> >> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64,
>>>> >> like a series of "C strings".
>>>> >
>>>> > No they don't, they look like (and are) an array of bytes.
>>>>
>>>> Not sure that "array" is the right word.
>>>
>>> It would be on some systems. MULTICS and EMAS come to mind.
>>
>> Yes, but he was referring to Unix & Unix-like systems. (And he was
>> wrong
>
> Yes I was - unix gets its file model from MULTICS, a file is a
> stream of bytes, TBF its only an array if it is seekable.
Partially. I was referring to files that are accessed by being mapped
into memory, which is how MULTICS did it. No distinction between files
and memory, so all (regular) files are arrays.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385291 is a reply to message #385249] |
Sun, 21 July 2019 08:39 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
> <jsavard@ecn.ab.ca> wrote:
>
>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>> Microsoft is considering alternatives once again
>>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>
>>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>> by developers inadvertently inserting memory corruption bugs into their
>>> C and C++ code. As Microsoft increases its code base and uses more Open
>>> Source Software in its code, this problem isn't getting better, it's
>>> getting worse.
>>
>> Rust never sleeps... that would perhaps have made a better reference.
>>
>> I think that a technical solution to buffer overflows, rather than just
>> expecting programmers to do a better job, *is* a good idea.
>>
>> However, my solution would not be to use different languages, at least not
>> directly, although C and C++ would probably be disqualified as an indirect
>> result. My solution would be to use a different *operating system*, one like MTS
>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>> general - looked, or were made to look, like a series of "Pascal strings",
>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>> of "C strings".
>>
>> That is, a stream of text comes with the length of each line in an "out-of-band"
>> form, instead of with lines separated one from another by some delimiter
>> character "in band". Therefore the record length now has an *absolute maximum*
>> due to the size of the field giving the length of the current record, with no
>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>> in time.
>>
>> Of course, this is just my baby duck syndrome talking...
>
> In MVS, records on DASD or tape are fixed length. C works fine. But
> one can still create overflows.
On MVS you can access UNIX files just fine.
NFS mounts and HFS file systems have been available for a long time now.
Null delimited strings have their advantages, for one thing, you don't
need to redesign your files to make a field longer.
I never had much problem keeping my data inside buffers.
I've certainly seen COBOL code overrun a table and wipe storage.
--
Dan Espen
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385292 is a reply to message #385258] |
Sun, 21 July 2019 08:42 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Sat, 20 Jul 2019 16:31:08 -0700, Peter Flass
> <peter_flass@yahoo.com> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
>>> <jsavard@ecn.ab.ca> wrote:
>>>
>>>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>>> > Rust in peace: Memory bugs in C and C++ code cause security issues so
>>>> > Microsoft is considering alternatives once again
>>>> > https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>> >
>>>> > The majority of vulnerabilities fixed and with a CVE assigned are caused
>>>> > by developers inadvertently inserting memory corruption bugs into their
>>>> > C and C++ code. As Microsoft increases its code base and uses more Open
>>>> > Source Software in its code, this problem isn't getting better, it's
>>>> > getting worse.
>>>>
>>>> Rust never sleeps... that would perhaps have made a better reference.
>>>>
>>>> I think that a technical solution to buffer overflows, rather than just
>>>> expecting programmers to do a better job, *is* a good idea.
>>>>
>>>> However, my solution would not be to use different languages, at least not
>>>> directly, although C and C++ would probably be disqualified as an indirect
>>>> result. My solution would be to use a different *operating system*, one like MTS
>>>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>>>> general - looked, or were made to look, like a series of "Pascal strings",
>>>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>>>> of "C strings".
>>>>
>>>> That is, a stream of text comes with the length of each line in an "out-of-band"
>>>> form, instead of with lines separated one from another by some delimiter
>>>> character "in band". Therefore the record length now has an *absolute maximum*
>>>> due to the size of the field giving the length of the current record, with no
>>>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>>>> in time.
>>>>
>>>> Of course, this is just my baby duck syndrome talking...
>>>
>>> In MVS, records on DASD or tape are fixed length.
>>
>> Not true, you have variable and “undefined” records, as well as spanned.
>
> A "variable length" record requires that the length be known before
> the record is written.
Unless, of course, you are calculating record length from your input
data.
You do have the backstop that max record length is defined by the JCL.
--
Dan Espen
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385294 is a reply to message #385267] |
Sun, 21 July 2019 10:16 |
|
|
Originally posted by: Carlos E.R.
On 21/07/2019 04.52, Quadibloc wrote:
> On Saturday, July 20, 2019 at 8:20:05 PM UTC-6, Carlos E.R. wrote:
>
>> What you say is absurd and doesn't relate to what I said.
>
>> In linux, for instance, you can have a single command line of many
>> thousands of chars, no matter what you say of "there *are* no 300 char
>> strings coming out of the input command"
>
> In Linux. But you can't do that in OS/360.
>
> Basically, try to type more than 72 characters, and your keyboard will lock up.
> Really. (Depending on the terminal type, of course.)
But that is not related to what we are talking about, to how different
languages treat memory arrays. It is just a problem with some operating
systems inputs.
In C, you can have a string of 100000 chars, it is no problem. Same in
Pascal. With different implementations, because pascal can do run time
range checking and C doesn't, AFAIK.
You don't like big strings? Fine, lets talk about a 30 and 50 char
string, the rationale is the same.
I said:
This strategy has still a problem: the size of the "string" may not be
the size of the storage area where it is stored. Like you can store an
89 char string in a 255 byte string var. Something else has to know that
you can not store a 300 char string there, and check for it.
Now I say:
This strategy has still a problem: the size of the "string" may not be
the size of the storage area where it is stored. Like you can store an
30 char string in a 50 byte string var. Something else has to know that
you can not store a 55 char string there, and check for it.
--
Cheers, Carlos.
|
|
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385304 is a reply to message #385294] |
Sun, 21 July 2019 12:59 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, July 21, 2019 at 8:16:09 AM UTC-6, Carlos E.R. wrote:
> You don't like big strings? Fine, lets talk about a 30 and 50 char
> string, the rationale is the same.
>
> I said:
>
> This strategy has still a problem: the size of the "string" may not be
> the size of the storage area where it is stored. Like you can store an
> 89 char string in a 255 byte string var. Something else has to know that
> you can not store a 300 char string there, and check for it.
>
> Now I say:
>
> This strategy has still a problem: the size of the "string" may not be
> the size of the storage area where it is stored. Like you can store an
> 30 char string in a 50 byte string var. Something else has to know that
> you can not store a 55 char string there, and check for it.
What you say is true in both cases. But it misses what I'm saying.
If you modify the whole operating system, so that applications making system
calls to do I/O will *never* get strings longer than 255 characters back from
those calls,
then, while it is still true that the programmer has to know to use buffers that
are 255 characters long, at least it's reasonable to expect that the programmer
_will_ know this.
Whereas, if one could get strings back of _any_ length from an I/O system call,
and one would have to take special precautions that vary depending on where
you're getting the input from, then the chance of a mistake being made
occasionally are much greater.
John Savard
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385306 is a reply to message #385258] |
Sun, 21 July 2019 14:52 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Sat, 20 Jul 2019 16:31:08 -0700, Peter Flass
> <peter_flass@yahoo.com> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
>>> <jsavard@ecn.ab.ca> wrote:
>>>
>>>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>>> > Rust in peace: Memory bugs in C and C++ code cause security issues so
>>>> > Microsoft is considering alternatives once again
>>>> > https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>> >
>>>> > The majority of vulnerabilities fixed and with a CVE assigned are caused
>>>> > by developers inadvertently inserting memory corruption bugs into their
>>>> > C and C++ code. As Microsoft increases its code base and uses more Open
>>>> > Source Software in its code, this problem isn't getting better, it's
>>>> > getting worse.
>>>>
>>>> Rust never sleeps... that would perhaps have made a better reference.
>>>>
>>>> I think that a technical solution to buffer overflows, rather than just
>>>> expecting programmers to do a better job, *is* a good idea.
>>>>
>>>> However, my solution would not be to use different languages, at least not
>>>> directly, although C and C++ would probably be disqualified as an indirect
>>>> result. My solution would be to use a different *operating system*, one like MTS
>>>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>>>> general - looked, or were made to look, like a series of "Pascal strings",
>>>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>>>> of "C strings".
>>>>
>>>> That is, a stream of text comes with the length of each line in an "out-of-band"
>>>> form, instead of with lines separated one from another by some delimiter
>>>> character "in band". Therefore the record length now has an *absolute maximum*
>>>> due to the size of the field giving the length of the current record, with no
>>>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>>>> in time.
>>>>
>>>> Of course, this is just my baby duck syndrome talking...
>>>
>>> In MVS, records on DASD or tape are fixed length.
>>
>> Not true, you have variable and undefined records, as well as spanned.
>
> A "variable length" record requires that the length be known before
> the record is written.
>
> A "spanned" record just spans across multiple fixed length records.
>
> You never run into the situation "read until a special character is
> encountered".
>>
Sure, read one character at a time into buffer and check for overflow,
stopping when the “special character” is read. Lots more overhead than
reading a counted string or a fixed-length record. I handle all the cases
in the Iron Spring PL/I runtime. Of course I buffer fixed-length chunks and
then pass the data to the user as required.
--
Pete
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385307 is a reply to message #385291] |
Sun, 21 July 2019 14:52 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
>> <jsavard@ecn.ab.ca> wrote:
>>
>>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>>> Microsoft is considering alternatives once again
>>>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>>
>>>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>>> by developers inadvertently inserting memory corruption bugs into their
>>>> C and C++ code. As Microsoft increases its code base and uses more Open
>>>> Source Software in its code, this problem isn't getting better, it's
>>>> getting worse.
>>>
>>> Rust never sleeps... that would perhaps have made a better reference.
>>>
>>> I think that a technical solution to buffer overflows, rather than just
>>> expecting programmers to do a better job, *is* a good idea.
>>>
>>> However, my solution would not be to use different languages, at least not
>>> directly, although C and C++ would probably be disqualified as an indirect
>>> result. My solution would be to use a different *operating system*, one like MTS
>>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>>> general - looked, or were made to look, like a series of "Pascal strings",
>>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>>> of "C strings".
>>>
>>> That is, a stream of text comes with the length of each line in an "out-of-band"
>>> form, instead of with lines separated one from another by some delimiter
>>> character "in band". Therefore the record length now has an *absolute maximum*
>>> due to the size of the field giving the length of the current record, with no
>>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>>> in time.
>>>
>>> Of course, this is just my baby duck syndrome talking...
>>
>> In MVS, records on DASD or tape are fixed length. C works fine. But
>> one can still create overflows.
>
> On MVS you can access UNIX files just fine.
> NFS mounts and HFS file systems have been available for a long time now.
>
> Null delimited strings have their advantages, for one thing, you don't
> need to redesign your files to make a field longer.
Mostly you do. You can make the record like longer, although you’d better
be sure everyone is aware of it. If your field is not last one in the
record it changes everything, unless the fields are also delimited, by FS
or such.
>
> I never had much problem keeping my data inside buffers.
> I've certainly seen COBOL code overrun a table and wipe storage.
>
Difficult to protect from, unless everything,is a hardware-protected
segment. Burroughs Large Systems could handle this easily. Multics would
wrap from the end of the segment to the beginning, I believe without
comment.
--
Pete
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385308 is a reply to message #385292] |
Sun, 21 July 2019 14:52 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Sat, 20 Jul 2019 16:31:08 -0700, Peter Flass
>> <peter_flass@yahoo.com> wrote:
>>
>>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>>> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
>>>> <jsavard@ecn.ab.ca> wrote:
>>>>
>>>> > On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>>> >> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>>> >> Microsoft is considering alternatives once again
>>>> >> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>> >>
>>>> >> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>>> >> by developers inadvertently inserting memory corruption bugs into their
>>>> >> C and C++ code. As Microsoft increases its code base and uses more Open
>>>> >> Source Software in its code, this problem isn't getting better, it's
>>>> >> getting worse.
>>>> >
>>>> > Rust never sleeps... that would perhaps have made a better reference.
>>>> >
>>>> > I think that a technical solution to buffer overflows, rather than just
>>>> > expecting programmers to do a better job, *is* a good idea.
>>>> >
>>>> > However, my solution would not be to use different languages, at least not
>>>> > directly, although C and C++ would probably be disqualified as an indirect
>>>> > result. My solution would be to use a different *operating system*, one like MTS
>>>> > or OS/360, in which text files on disk - and, therefore, input-output streams in
>>>> > general - looked, or were made to look, like a series of "Pascal strings",
>>>> > instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>>>> > of "C strings".
>>>> >
>>>> > That is, a stream of text comes with the length of each line in an "out-of-band"
>>>> > form, instead of with lines separated one from another by some delimiter
>>>> > character "in band". Therefore the record length now has an *absolute maximum*
>>>> > due to the size of the field giving the length of the current record, with no
>>>> > chance of a buffer overflow if the delimiter character doesn't happen to turn up
>>>> > in time.
>>>> >
>>>> > Of course, this is just my baby duck syndrome talking...
>>>>
>>>> In MVS, records on DASD or tape are fixed length.
>>>
>>> Not true, you have variable and “undefined” records, as well as spanned.
>>
>> A "variable length" record requires that the length be known before
>> the record is written.
>
> Unless, of course, you are calculating record length from your input
> data.
>
> You do have the backstop that max record length is defined by the JCL.
>
Most real languages, not toy languages like C, let the programmer define
the maximum record length, if the OS doesn’t do it.
--
Pete
|
|
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385310 is a reply to message #385261] |
Sun, 21 July 2019 15:22 |
|
|
Originally posted by: antispam
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Saturday, July 20, 2019 at 2:59:28 PM UTC-6, anti...@math.uni.wroc.pl wrote:
>
>> Sorry, OS solve _nothing_, main danger is due to data coming from
>> network, such data naturaly has structure of effectively unbounded
>> stream and OS can not change that.
>
> The OS had *better* change that, or it won't be possible to write a program that
> can access data coming from the network. The system calls for input all return
> records of bounded length, and records of bounded length *only*.
>
> In a case like this, of course, to handle the data, the program will still have
> to check on the length of packets, as it builds them up from the fixed maximum
> length chunks the operating system will let it have. When a programmer has to do
> this, though, there is an awareness that bounds checking is needed: one is
> forced to do more than just say "readlin(my_string);" in order to assemble a
> packet.
The OS interface _already_ uses length: 'read' and 'write' take
length argument so that is not a problem. Slightly higher level
C has 'gets()' which does not check for buffer length, but this
is C specific (C on MVS surely had this too) and depreciated
for many years (alternatives have length field). Most real
world buffer overflow problems deal with cases that programmes
is aware of the problem but made mistake. Two representative
cases where I was involoved:
- overflow in Bison parser. Parser has stack and checks if
there is space to push required number of tokens. On one
code path parser checked if there is space to push one
token, but on this path in somewhat obscure case parser
pushed two tokens. That was bug in "parser skeleton"
which was part of bison. I learned about problem because
"my" parser crashed (actually that was reported by a user).
- wrong calculation: program was computning buffer size and
due to wrong calculation buffer was too small. And buffer
was dynamically allocated and should be always of right
size (but in fact was too small).
--
Waldek Hebisch
|
|
|
|
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385313 is a reply to message #385252] |
Sun, 21 July 2019 15:35 |
|
|
Originally posted by: antispam
Peter Flass <peter_flass@yahoo.com> wrote:
> <antispam@math.uni.wroc.pl> wrote:
>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>>> Microsoft is considering alternatives once again
>>>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>>
>>>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>>> by developers inadvertently inserting memory corruption bugs into their
>>>> C and C++ code. As Microsoft increases its code base and uses more Open
>>>> Source Software in its code, this problem isn't getting better, it's
>>>> getting worse.
>>>
>>> Rust never sleeps... that would perhaps have made a better reference.
>>>
>>> I think that a technical solution to buffer overflows, rather than just
>>> expecting programmers to do a better job, *is* a good idea.
>>>
>>> However, my solution would not be to use different languages, at least not
>>> directly, although C and C++ would probably be disqualified as an indirect
>>> result. My solution would be to use a different *operating system*, one like MTS
>>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>>> general - looked, or were made to look, like a series of "Pascal strings",
>>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>>> of "C strings".
>>>
>>> That is, a stream of text comes with the length of each line in an "out-of-band"
>>> form, instead of with lines separated one from another by some delimiter
>>> character "in band". Therefore the record length now has an *absolute maximum*
>>> due to the size of the field giving the length of the current record, with no
>>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>>> in time.
>>
>> Sorry, OS solve _nothing_, main danger is due to data coming from
>> network, such data naturaly has structure of effectively unbounded
>> stream and OS can not change that. Also, now problems _directly_
>> with data coming from outside are rare. Main problem is that
>> data travels internally in program and appears in a priori
>> unexpected places. Problem is mainly due to C (C++ without
>> C compatiblity would be OK). And solution is well-known
>> for long time, it was invented in Pascal (and Java uses
>> essentially the same solution as Pascal). More technically,
>> in C given a pointer compiler does not know size of
>> correcponding buffer. In Pascal given a pointer compiler
>> can compute size of buffer and automatically inserts
>> check so that each access is in bounds. In seventies
>> automatic bounds checking was rejected as too expensive.
>> Modern tests show that average cost is about 10% (less than
>> say Spectre mitigation). Some folks may still consider
>> this 10% as "too expensive", but IMO most people would
>> gladly accept such performance loss for freedom of
>> buffer overflows...
>>
>
> If the compiled code doesn?t check, the programmer has to check, unless, of
> course ?the string length can never exceed x.? The overhead is the same in
> either case, or maybe more to do the checking in the application.
Let us assume normal program which does not play tricks with
exception handling. If correct, such program will never made
out of bounds reference, checks are part of program logic.
The 10% I write is average overhead due to extra checks inserted
automatically by compiler. This assumes optimizing compiler,
which frequently can notice that program already contains
a check and avoids inserting clearly redundant checks. But
still there is significant number of places where proving
that there is no out of bound access requires complicated
reasoning, beyond compiler capability. And small number
of places where programmer was wrong and inserted check
is needed (not redundant)...
If you ask about source of this data, there are several:
- publications about existing checking compilers
- my personal experience with GNU Pascal (in later versions
it is possible to turn on (or off) checks)
--
Waldek Hebisch
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385314 is a reply to message #385307] |
Sun, 21 July 2019 16:10 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
>>> <jsavard@ecn.ab.ca> wrote:
>>>
>>>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>>> > Rust in peace: Memory bugs in C and C++ code cause security issues so
>>>> > Microsoft is considering alternatives once again
>>>> > https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>> >
>>>> > The majority of vulnerabilities fixed and with a CVE assigned are caused
>>>> > by developers inadvertently inserting memory corruption bugs into their
>>>> > C and C++ code. As Microsoft increases its code base and uses more Open
>>>> > Source Software in its code, this problem isn't getting better, it's
>>>> > getting worse.
>>>>
>>>> Rust never sleeps... that would perhaps have made a better reference.
>>>>
>>>> I think that a technical solution to buffer overflows, rather than just
>>>> expecting programmers to do a better job, *is* a good idea.
>>>>
>>>> However, my solution would not be to use different languages, at least not
>>>> directly, although C and C++ would probably be disqualified as an indirect
>>>> result. My solution would be to use a different *operating system*, one like MTS
>>>> or OS/360, in which text files on disk - and, therefore, input-output streams in
>>>> general - looked, or were made to look, like a series of "Pascal strings",
>>>> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>>>> of "C strings".
>>>>
>>>> That is, a stream of text comes with the length of each line in an "out-of-band"
>>>> form, instead of with lines separated one from another by some delimiter
>>>> character "in band". Therefore the record length now has an *absolute maximum*
>>>> due to the size of the field giving the length of the current record, with no
>>>> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>>>> in time.
>>>>
>>>> Of course, this is just my baby duck syndrome talking...
>>>
>>> In MVS, records on DASD or tape are fixed length. C works fine. But
>>> one can still create overflows.
>>
>> On MVS you can access UNIX files just fine.
>> NFS mounts and HFS file systems have been available for a long time now.
>>
>> Null delimited strings have their advantages, for one thing, you don't
>> need to redesign your files to make a field longer.
>
> Mostly you do. You can make the record like longer, although you’d better
> be sure everyone is aware of it. If your field is not last one in the
> record it changes everything, unless the fields are also delimited, by FS
> or such.
???
There is no record.
Files are streams of bytes. Add a byte to the last field it is
longer. There may or may not be some truncation on reports or displays.
At least you don't need FILLER, new copy books, a file re-org.
>> I never had much problem keeping my data inside buffers.
>> I've certainly seen COBOL code overrun a table and wipe storage.
>>
>
> Difficult to protect from, unless everything,is a hardware-protected
> segment. Burroughs Large Systems could handle this easily. Multics would
> wrap from the end of the segment to the beginning, I believe without
> comment.
???
For COBOL, just be sure to bounds check properly.
Hardware protection for all arrays would be a performance killer.
--
Dan Espen
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385315 is a reply to message #385247] |
Sun, 21 July 2019 16:10 |
|
|
Originally posted by: antispam
Carlos E.R. <robin_listas@es.invalid> wrote:
> On 20/07/2019 21.18, Quadibloc wrote:
>> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>> Microsoft is considering alternatives once again
>>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>
>>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>> by developers inadvertently inserting memory corruption bugs into their
>>> C and C++ code. As Microsoft increases its code base and uses more Open
>>> Source Software in its code, this problem isn't getting better, it's
>>> getting worse.
>>
>> Rust never sleeps... that would perhaps have made a better reference.
>>
<snip>
>
> This strategy has still a problem: the size of the "string" may not be
> the size of the storage area where it is stored. Like you can store an
> 89 char string in a 255 byte string var. Something else has to know that
> you can not store a 300 char string there, and check for it.
>
> For example, the pascal compiler (the Borland variant at least) knows
> the size of variables, arrays as such, and can prevent an out of bounds
> access (unless the programmer disables the run time checks because they
> make the program slower, which many do), and as long as the variables
> are not dynamic, assigned on the heap and accessed by pointers, it
> works. Crashing programs on those accesses.
Actually, Pascal checking works fine for all variables, they
may be allocated on heap and accessed by pointers. In classic
Pascal there is significant restriction: size is determined
based on type and type must have sizes known at compile time.
In Extended Pascal (as implemented in say GNU Pascal)
sizes can be determined (vary) at runtime, so you get fully
dynamic allocation with automatic bounds checking.
In old PL/1 pointers effectively lost type information, so
checking of accesses going via pointers was quite limited.
Modern PL/1 replaces old pointers by Pascal like (IIRC
IBM calls them "handles"). Actually, after Pascal
was invented most languages adopted Pascal concept of
pointer so that pointer has type and knowing type one
can determine sizes (say via hidden length fields).
Java officially does not have pointers but its safety
concepts and in particular handling of references by
JVM is based on Pascal (Wirth) idea. Notable exception
is C and relatives, where pointer loses information
about size. C++ tries to correct sitiation offering
new string and array types that know their size,
but there is still problem due to legacy code.
--
Waldek Hebisch
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385316 is a reply to message #385308] |
Sun, 21 July 2019 16:12 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On Sat, 20 Jul 2019 16:31:08 -0700, Peter Flass
>>> <peter_flass@yahoo.com> wrote:
>>>
>>>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>>> > On Sat, 20 Jul 2019 12:18:31 -0700 (PDT), Quadibloc
>>>> > <jsavard@ecn.ab.ca> wrote:
>>>> >
>>>> >> On Thursday, July 18, 2019 at 1:11:24 PM UTC-6, Anne & Lynn Wheeler wrote:
>>>> >>> Rust in peace: Memory bugs in C and C++ code cause security issues so
>>>> >>> Microsoft is considering alternatives once again
>>>> >>> https://www.theregister.co.uk/2019/07/18/microsoft_rust_secu rity/
>>>> >>>
>>>> >>> The majority of vulnerabilities fixed and with a CVE assigned are caused
>>>> >>> by developers inadvertently inserting memory corruption bugs into their
>>>> >>> C and C++ code. As Microsoft increases its code base and uses more Open
>>>> >>> Source Software in its code, this problem isn't getting better, it's
>>>> >>> getting worse.
>>>> >>
>>>> >> Rust never sleeps... that would perhaps have made a better reference.
>>>> >>
>>>> >> I think that a technical solution to buffer overflows, rather than just
>>>> >> expecting programmers to do a better job, *is* a good idea.
>>>> >>
>>>> >> However, my solution would not be to use different languages, at least not
>>>> >> directly, although C and C++ would probably be disqualified as an indirect
>>>> >> result. My solution would be to use a different *operating system*, one like MTS
>>>> >> or OS/360, in which text files on disk - and, therefore, input-output streams in
>>>> >> general - looked, or were made to look, like a series of "Pascal strings",
>>>> >> instead of, as in Unix, DOS, MacOS, and even on the Commodore 64, like a series
>>>> >> of "C strings".
>>>> >>
>>>> >> That is, a stream of text comes with the length of each line in an "out-of-band"
>>>> >> form, instead of with lines separated one from another by some delimiter
>>>> >> character "in band". Therefore the record length now has an *absolute maximum*
>>>> >> due to the size of the field giving the length of the current record, with no
>>>> >> chance of a buffer overflow if the delimiter character doesn't happen to turn up
>>>> >> in time.
>>>> >>
>>>> >> Of course, this is just my baby duck syndrome talking...
>>>> >
>>>> > In MVS, records on DASD or tape are fixed length.
>>>>
>>>> Not true, you have variable and “undefined” records, as well as spanned.
>>>
>>> A "variable length" record requires that the length be known before
>>> the record is written.
>>
>> Unless, of course, you are calculating record length from your input
>> data.
>>
>> You do have the backstop that max record length is defined by the JCL.
>
> Most real languages, not toy languages like C, let the programmer define
> the maximum record length, if the OS doesn’t do it.
All these UNIX guys get by with no records at all.
I guess they are only playing with toys.
--
Dan Espen
|
|
|
|
| Re: Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [message #385322 is a reply to message #385294] |
Sun, 21 July 2019 18:04 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
"Carlos E.R." <robin_listas@es.invalid> writes:
> On 21/07/2019 04.52, Quadibloc wrote:
>> On Saturday, July 20, 2019 at 8:20:05 PM UTC-6, Carlos E.R. wrote:
>>
>>> What you say is absurd and doesn't relate to what I said.
>>
>>> In linux, for instance, you can have a single command line of many
>>> thousands of chars, no matter what you say of "there *are* no 300 char
>>> strings coming out of the input command"
>>
>> In Linux. But you can't do that in OS/360.
>>
>> Basically, try to type more than 72 characters, and your keyboard will lock up.
>> Really. (Depending on the terminal type, of course.)
>
> But that is not related to what we are talking about, to how different
> languages treat memory arrays. It is just a problem with some operating
> systems inputs.
>
> In C, you can have a string of 100000 chars, it is no problem. Same in
> Pascal. With different implementations, because pascal can do run time
> range checking and C doesn't, AFAIK.
>
> You don't like big strings? Fine, lets talk about a 30 and 50 char
> string, the rationale is the same.
>
> I said:
>
> This strategy has still a problem: the size of the "string" may not be
> the size of the storage area where it is stored. Like you can store an
> 89 char string in a 255 byte string var. Something else has to know that
> you can not store a 300 char string there, and check for it.
>
> Now I say:
>
> This strategy has still a problem: the size of the "string" may not be
> the size of the storage area where it is stored. Like you can store an
> 30 char string in a 50 byte string var. Something else has to know that
> you can not store a 55 char string there, and check for it.
>
The Burroughs Medium systems strings had a hardware decriptor that contained
four addresses - the start and end of the storage area, and the start and
end of the string within the storage area. The string instructions operated
on that descriptor.
|
|
|
|
Members
Search
Help
Register
Login
Home
