vulnerabilities

M

Merrill & Michele

Elliott Back said:
A language doesn't have a "vulnerability." Vulnerabilities are
properties of poorly written programs. To enumerate the ways in which a
program can be poorly written is ... tedious. You could things like
"data injection" and "data execution" to your list, if you wanted, but
this only scratches the surface of the wrong things you can do in C.

#define elliot beck

_penry

/*your skills were not un-noticed*/
 
W

wijhierbeneden

Elliott Back said:
A language doesn't have a "vulnerability." Vulnerabilities are
properties of poorly written programs. To enumerate the ways in which a
program can be poorly written is ... tedious. You could things like
"data injection" and "data execution" to your list, if you wanted, but
this only scratches the surface of the wrong things you can do in C.

A language HAS vulnerabilities. Ok the vulnerabilities could be caused
by the programmer (race conditions, off-by-one). But in Ada you can't
have numeric under- and overflow/ unsigned-signed mismatch/
bufferoveflow/format string bugs... In Java you don't have a unsigned
type/ bufferoverflow/heapoverflow/... . So C/C++ is vulnerable for
such faults. All I want to know is that there are even more of those
problems in C/C++. You can call it a vulnerabilities of C/C++ or not
it is a vulnerability that reside in programs written in those
languages.
 
F

Flash Gordon

On 26 Oct 2004 00:59:27 -0700
A language HAS vulnerabilities. Ok the vulnerabilities could be caused
by the programmer (race conditions, off-by-one). But in Ada you can't
have numeric under- and overflow/

So what happens if you add 1 to an integer that is at it's maximum
value? It is still an overflow (in the normal sense of the word) even if
the language defines what happens. The programmer still has to make an
effort to handle it, whether that means catching the exception and
handling it gracefully or (as in C with unsigned types) detecting the
wrap around.

unsigned-signed mismatch/
bufferoveflow/format string bugs... In Java you don't have a unsigned
type/ bufferoverflow/heapoverflow/...

You don't have heap overflow in C. If malloc/realloc/calloc cannot
obtain enough memory then they fail and return a null pointer and the
heap is still intact.

Java can run out of memory on creating an object (say, another node on a
linked list) which is on the Java equivalent of a heap.

In saying Java doesn't have buffer overflows, I assume you mean it
is required to generate an exception on access beyond the end of an
array.
. So C/C++ is vulnerable for
such faults. All I want to know is that there are even more of those
problems in C/C++. You can call it a vulnerabilities of C/C++ or not
it is a vulnerability that reside in programs written in those
languages.

There are more ways for a programmer to shoot him/herself in the foot
with C or C++ than with Java and probably ADA, but neither Java nor ADA
are automatically safe, they both still require that the programmer
deals with issues such as resource exhaustion and what happens when you
increment an integer beyond its maximum value (whatever Ada and Java do
may not give the result you want without further work).
 
D

Dan Pop

In said:
A language HAS vulnerabilities. Ok the vulnerabilities could be caused
by the programmer (race conditions, off-by-one). But in Ada you can't
have numeric under- and overflow/ unsigned-signed mismatch/
bufferoveflow/format string bugs...

Was the code that destroyed an ARIANE V rocket written in C or Ada?

Dan
 
M

Martin Ambuhl

Dan said:
Was the code that destroyed an ARIANE V rocket written in C or Ada?

Irrelevant. The culprit was "code reuse." Code used for the Ariane IV
which kept a pre-launch alignment process running after lift-off beyond
its normal time-limit was not removed for the Ariane V. The Ariane V
not only had no need for this code, but could not tolerate its activation.
 
D

Dan Pop

In said:
Irrelevant. The culprit was "code reuse."

It is perfectly relevant to the point it was supposed to make: intrinsic
language safety counts for very little in the safety of the final program.

Too bad you missed it.

Dan
 
M

Martin Ambuhl

Dan said:
It is perfectly relevant to the point it was supposed to make: intrinsic
language safety counts for very little in the safety of the final program.

Too bad you missed it.

Sorry, I missed the part where you actually wrote anything more than
"Was the code that destroyed an ARIANE V rocket written in C or Ada?"
That question contains nothing which I could have missed.
 
D

Dan Pop

In said:
Sorry, I missed the part where you actually wrote anything more than
"Was the code that destroyed an ARIANE V rocket written in C or Ada?"
That question contains nothing which I could have missed.

You were supposed to be able to figure out the rest by yourself. Too bad
you weren't.

Dan
 
M

Martin Ambuhl

Dan said:
You were supposed to be able to figure out the rest by yourself. Too bad
you weren't.

I don't know what is bothering you. Making pointless snide remarks is
beneath you. Try kicking a cat; maybe that will help you.
 
D

Dan Pop

In said:
I don't know what is bothering you. Making pointless snide remarks is
beneath you. Try kicking a cat; maybe that will help you.

Not unless I could find the cat responsible for your obtuseness.

Dan
 
D

Dave Thompson

On Fri, 22 Oct 2004 20:16:40 +0200, jacob navia
C++ accepts most of the C89 syntax. Yes, there are
several problems with some C constructs, but *most*
of C is still legal C++ I am sorry, this is an evidence.
Given this corrected claim (not "all") there are still a few cases
where C++ fixes to a minor extent some of the problems from C.

Biggest is that functions must be declared and in prototype syntax,
which eliminates some of the opportunities for mismatching calls.
Further, though it isn't inherent in the language or officially
required, all practical C++ implementations to support overloading use
"typesafe" linking which catches some -- not all -- mismatched
function declarations, while C implementations (except yours) don't
need to and usually don't.

The implicit conversion from void* to any (possibly wrong) object
pointer is gone, although you still can do the (explicit) cast with
equally bad results. enums are distinct types and don't implicitly
convert from other enums (that were intended to be distinct), or from
integers although IME that is less often a problem.

A few string functions like strchr are overloaded to be const-safe,
and string literal values are officially const -- although they still
deprecatedly convert to a nonconst pointer (yuck!).

And C++ provides _alternatives_ to some of the things that are often
problems in C: std::string, vector and valarray, *streams with << >>,
new/delete (though delete[] is still a landmine), smart pointers that
can force initialization and do reference counting and/or GC. But
you're right that nearly all the things that are commonly problems in
C are still possible in C++.

- David.Thompson1 at worldnet.att.net
 
D

Dave Thompson

Dan Pop wrote:

Irrelevant. The culprit was "code reuse." Code used for the Ariane IV
which kept a pre-launch alignment process running after lift-off beyond
its normal time-limit was not removed for the Ariane V. The Ariane V
not only had no need for this code, but could not tolerate its activation.
AIRandUI it wasn't the activation(? really continued running) as such,
although it wasn't *needed* at all after liftoff on 5 as it had for
some minutes on 4. It was the continued running while 5 accelerated
faster than 4, reaching a velocity or displacement (I don't recall
which) outside limits specified for 4 causing a kind of overflow trap
in _one_ (nav) computer, the "display" of which was then
misinterpreted by a different (control) computer, causing it to go out
of control -- it wrongly thought it was off course and commanded the
engines too far over trying to correct this nonexistent error.

So yes the problem was reuse, both for functionality not actually
needed or appropriate, _and_ outside the limits originally specified,
_plus_ incorrect (undesigned) interaction with a different system.

- David.Thompson1 at worldnet.att.net
 
P

Peter Pichler

Malcolm said:
One of the main problems with C is that there is no error-handling
mechanism, so exceptions must be coded as part of the normal flow of the
program. This can make testing very difficult.

ITYM very easy :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top