clarificaiton on the effects of managed languages on buffers

[linuxfan66]

this particular controversy came up in a thread i was in early and never got resolved according to this you cannot buffer overflow on a manage language setup like .net or java because enforces limits on buffers that cant be easily crossed. 

the other way to prevent them listed is to use safety libraries with c/c++.

 

this begs a question for me why do why write security relevant libraries with beffer overruns/underfaults/faults are are major threat(heartbleed, all sort of browser drivebys, and stagefright library) in languages that are inherently vulnerable if making it managed prevents it from happening as suggested above.

 

can someone who qualified answer and cite their sources?

 

[manon_gfx]

The only source that I have is that I am a grame programming student, but I can give my two cents.

A lot of software (like OpenSSL) require a lot of performance. By writing it in a language like C or C++, the programmer gets a lot more options for optimizing. This comes at a cost, and that is safety. Now in theory, you should be fine, as long as you pay a lot of attention. However, software is written by humans, and humans make mistakes. They can be very small, or they can be huge. Bug free software is just incredibly difficult to write.

There is another big advantage of writing your program in C or C++, and that is that you can write a wrapper for it in almost any language and have it work. Want to run your code from some python, some C# and some Java, that is no problem. All that has to be done is creating an extra interface (which is way way way less work than implementing the whole library in another language).

I do think that if your software doesn't need to be the most optimized thing ever, writing it in a managed language like C# is fine, and will save you from a lot of potential bugs. But if you were to write a high performance library, you just have to use an 'unsafe' language.
 

[SpaceNugget]

this particular controversy came up in a thread i was in early and never got resolved according to this you cannot buffer overflow on a manage language setup like .net or java because enforces limits on buffers that cant be easily crossed. 

the other way to prevent them listed is to use safety libraries with c/c++.

 

this begs a question for me why do why write security relevant libraries with beffer overruns/underfaults/faults are are major threat(heartbleed, all sort of browser drivebys, and stagefright library) in languages that are inherently vulnerable if making it managed prevents it from happening as suggested above.

 

can someone who qualified answer and cite their sources?

 

This is really kind of a strange question, if you do things incorrectly in a managed or unmanaged language you can end up with a security flaw. Just because you write something in an unmanaged language doesn't mean you are magically vulnerable to a buffer overflow attack, as long as you sanitize your inputs (which you do in both types of languages) and perform checks to make sure that they are in range you are fine.

[Ciccioo]

This is really kind of a strange question, if you do things incorrectly in a managed or unmanaged language you can end up with a security flaw. Just because you write something in an unmanaged language doesn't mean you are magically vulnerable to a buffer overflow attack, as long as you sanitize your inputs (which you do in both types of languages) and perform checks to make sure that they are in range you are fine.

his point stands though.

 

 

unmanaged languages leave the possibility of buffer overflows, which caused huge problems in the recent past. those problems would have never existed if the SSL implementations were written in java or something. the time it takes to rewrite the implementation and the slight eventual performance decrese are orders of magnitude less of a problem than all of the security data of many many servers worldwide being potentially exposed.

 

for how i see it, it's just the good ol' "good enough", nobody decided to make the step towards a much stronger security.

 

what really surprises me is that buffer overflow bugs exist. like, isn't that the first thing you would quadruple-check if you were writing a security library? how is it possible that an unchecked input made it to production code without anybody spotting it?

[SpaceNugget]

his point stands though.

 

 

unmanaged languages leave the possibility of buffer overflows, which caused huge problems in the recent past. those problems would have never existed if the SSL implementations were written in java or something. the time it takes to rewrite the implementation and the slight eventual performance decrese are orders of magnitude less of a problem than all of the security data of many many servers worldwide being potentially exposed.

 

for how i see it, it's just the good ol' "good enough", nobody decided to make the step towards a much stronger security.

 

what really surprises me is that buffer overflow bugs exist. like, isn't that the first thing you would quadruple-check if you were writing a security library? how is it possible that an unchecked input made it to production code without anybody spotting it?

well yea actually heartbleed isn't that kind of buffer overflow attack. it could easily exist if ssl were written in java. and conversely it was easily fixed without language handled array bound checking. if you actually read what i wrote there is the possibility of buffer overflow type attacks in any language. managed languages are not more or less secure. security is in system architecture.

 

edit: a better way to say what I am trying to say is that only a bad carpenter blames his tools. bugs are not a result of the language you are writing in.

[Ciccioo]

well yea actually heartbleed isn't that kind of buffer overflow attack. it could easily exist if ssl were written in java. and conversely it was easily fixed without language handled array bound checking. if you actually read what i wrote there is the possibility of buffer overflow type attacks in any language. managed languages are not more or less secure. security is in system architecture.

 

edit: a better way to say what I am trying to say is that only a bad carpenter blames his tools. bugs are not a result of the language you are writing in.

can you buffer overflow in java?

and isn't heartbleed a buffer overflow? i barely read something about it, but i was sure it was a BO

[fizzlesticks]

can you buffer overflow in java?

and isn't heartbleed a buffer overflow? i barely read something about it, but i was sure it was a BO

It wasn't a buffer overflow.

The user would pass in some data and say how long that data is. So if the user sent the data 'mouse' but said it was 64KB long, they would allocate a 64KB buffer then copy 'mouse' into that buffer and echo the whole thing back the user. Since the real data was only 5 bytes the 64KB - 5bytes would have been old data sitting in memory still. 

AFAIK the problem would have been the same if they did it that way in Java/C#.

 

http://xkcd.com/1354/

[Ciccioo]

It wasn't a buffer overflow.

The user would pass in some data and say how long that data is. So if the user sent the data 'mouse' but said it was 64KB long, they would allocate a 64KB buffer then copy 'mouse' into that buffer and echo the whole thing back the user. Since the real data was only 5 bytes the 64KB - 5bytes would have been old data sitting in memory still. 

AFAIK the problem would have been the same if they did it that way in Java/C#.

 

http://xkcd.com/1354/

so yeah, i knew it right... well i thought it was a buffer overflow, since do things past the limits of your buffer.

so, is there no system that checks memory accesses of this kind?

[fizzlesticks]

so yeah, i knew it right... well i thought it was a buffer overflow, since do things past the limits of your buffer.

so, is there no system that checks memory accesses of this kind?

Nothing is happening outside the buffer, they're just creating a buffer that's too big.

 

And the only thing I can think of that would stop it is to zero the memory when you allocate it. (or just not have the bug)

[linuxfan66]

It wasn't a buffer overflow.

The user would pass in some data and say how long that data is. So if the user sent the data 'mouse' but said it was 64KB long, they would allocate a 64KB buffer then copy 'mouse' into that buffer and echo the whole thing back the user. Since the real data was only 5 bytes the 64KB - 5bytes would have been old data sitting in memory still.

AFAIK the problem would have been the same if they did it that way in Java/C#.

http://xkcd.com/1354/

Doesn't .net and Java sanitise memory in the location of a new variable? Or it just .net?

Also I was aware heart bleed wasn't a buffer overrun but I still found the the concept of managed code that could have kept that spot clean you couldn't go over and you couldnt use data that should have cleaned out.

What's the use of perfect optimisation if it creates needless risk.

[fizzlesticks]

Doesn't .net and Java sanitise memory in the location of a new variable? Or it just .net?

They initialize arrays to some default value, I thought it was just a debug mode thing but looks like they do it in release too. So ya that would stop the problem.

[madknight3]

@linuxfan66 your question seems to be reducing to something along the lines of "Why even bother using C and C++ at all?"

 

Whether you write managed or unmanaged code there will be security risks. Managed code removes some of the effort and security risks that unmanaged code has and many people do choose to use a variety of languages over C and C++ so they don't have to worry about these things. However, C and C++ are still widely used for a variety of reasons and there isn't always an acceptable substitute.

 

Every language has it's pros and cons. In order to get the benefits of a language, you have to also deal with the drawbacks. It's up to the business/developers to look at their options, weigh the pros and cons, and choose an appropriate tool for the job. Whether you go with C, C++, D, Rust, Go, C#, Scala, Haskell, Python, or something else can depend on a lot of factors. Sometimes it comes down to technical reasons. Sometimes it comes down to business reasons.

[SpaceNugget]

Doesn't .net and Java sanitise memory in the location of a new variable? Or it just .net?

Also I was aware heart bleed wasn't a buffer overrun but I still found the the concept of managed code that could have kept that spot clean you couldn't go over and you couldnt use data that should have cleaned out.

What's the use of perfect optimisation if it creates needless risk.

its not a risk, like i said bugs are not built into a language. there is no part of java that you can't replicate in c. The actual checking mechanism (the java virtual machine) is written in c.

 

you keep implying that buffer overflow attacks are part of unmanaged languages but they aren't, you can cause a buffer overflow in either language and you can prevent them in either language.

[linuxfan66]

its not a risk, like i said bugs are not built into a language. there is no part of java that you can't replicate in c. The actual checking mechanism (the java virtual machine) is written in c.

you keep implying that buffer overflow attacks are part of unmanaged languages but they aren't, you can cause a buffer overflow in either language and you can prevent them in either language.

Why aren't library wide buffer cleaners always in security libraries...

Also I accept that c/c++ is needed for kernels, drivers, low level code, and low security performance orientated libraries.

I primarily take issue with libraries for primary security purposes written in languages that make buffer related bugs easy without an attachment to guarantee buffer safety

[SpaceNugget]

Why aren't library wide buffer cleaners always in security libraries...

Also I accept that c/c++ is needed for kernels, drivers, low level code, and low security performance orientated libraries.

I primarily take issue with libraries for primary security purposes written in languages that make buffer related bugs easy without an attachment to guarantee buffer safety

 

Buffer related bugs are not "easy". security libraries are not written by idiots, the type of overflow attack that is prevented by managed arrays is not something that gets past the second glance of a professional programmer, let alone code peer reviews and the like. get it through your head, bugs are not a part of a language,

 

also, the number of significantly exploitable arrays over the number of arrays in code in the wild is an unbelievably small number.

[linuxfan66]

Buffer related bugs are not "easy". security libraries are not written by idiots, the type of overflow attack that is prevented by managed arrays is not something that gets past the second glance of a professional programmer, let alone code peer reviews and the like. get it through your head, bugs are not a part of a language,

also, the number of significantly exploitable arrays over the number of arrays in code in the wild is an unbelievably small number.

I never said bugs are part of the language I only said they make it easier...and an army of professional programmers can't even write prefer code. Worst case scenario has happened forgive me for asking why we don't implement a permanent blanket that minimises the effects of human error

[SpaceNugget]

I never said bugs are part of the language I only said they make it easier...and an army of professional programmers can't even write prefer code. Worst case scenario has happened forgive me for asking why we don't implement a permanent blanket that minimises the effects of human error

Thats the thing, you aren't asking, you are telling.

 

why write code at all, if there is no code there are no security holes.

 

errors that are caused by unchecked buffer access are preventable by other measures, and is a very tiny risk.

 

You are saying that north americans should all move to france because there is a pothole in north america,

 

A. You can just fix the pothole.

B. Why would you move because of a pothole?

C. THERE ARE POTHOLES IN FRANCE TOO.

[linuxfan66]

Thats the thing, you aren't asking, you are telling.

why write code at all, if there is no code there are no security holes.

errors that are caused by unchecked buffer access are preventable by other measures, and is a very tiny risk.

You are saying that north americans should all move to france because there is a pothole in north america,

A. You can just fix the pothole.

B. Why would you move because of a pothole?

C. THERE ARE POTHOLES IN FRANCE TOO.

Your saying

An automatic buffer sanitiser/regulator attached to the existing code is bad idea?

[SpaceNugget]

Your saying

An automatic buffer sanitiser/regulator attached to the existing code is bad idea?

I didn't say that at all, don't put words in my mouth.

[linuxfan66]

I didn't say that at all, don't put words in my mouth.

Wasn't trying to and that's what I was trying to suggest earlier. It seemed to me heartbleed particularly would have been impossible if a buffer manager prevented unintended leaving or exiting where it should be. And such thing should be mandatory on high security libraries as an insurance policy. Perfect Optimisation been darned

[SpaceNugget]

Heartbleed is not a buffer overflow. it would have been possible to have that bug if ssl had been implemented in any language.

 

its not a trade-off of security vs optimization because neither type of language is more secure than the other.

 

its two ways of doing the exact same thing.

[linuxfan66]

Heartbleed is not a buffer overflow. it would have been possible to have that bug if ssl had been implemented in any language.

its not a trade-off of security vs optimization because neither type of language is more secure than the other.

its two ways of doing the exact same thing.

I knew hb was a buffer under run where you underfill the buffer because data was left from a previous variable in the same spot. If it had been sanitised before use...

By leaving i meant data in their by accident that shouldn't be there...

[SpaceNugget]

a buffer underrun is completely unrelated to a buffer overflow.

 

I'm just going to start copy pasting this as a reply until you actually listen:

 

"Heartbleed would have been possible if ssl had been implemented in any language"

[linuxfan66]

a buffer underrun is completely unrelated to a buffer overflow.

I'm just going to start copy pasting this as a reply until you actually listen:

"Heartbleed would have been possible if ssl had been implemented in any language"

Fine if the xkcd comic referenced in this thread is true. Does heart bleed occur because a new variable is made or existing one is reused. Because I know for a fact .net wipes values of new variables before adding new content to them. You can't underrun a blank variable it will return content you added and not latent memory contents.

I suspect did not realise variable reuse is being done

[SpaceNugget]

Fine if the xkcd comic referenced in this thread is true. Does heart bleed occur because a new variable is made or existing one is reused. Because I know for a fact .net wipes values of new variables before adding new content to them. You can't underrun a blank variable it will return content you added and not latent memory contents.

I suspect did not realise variable reuse is being done

 

you might want to try to understand what you wrote here because I certainly can't

 

also:

 

"Heartbleed would have been possible if ssl had been implemented in any language"