[Solved]Buffer overflows

[Zvoni]

If something goes wrong eventually someone ends up with the blame.

I just read that the big AI companies made a pact with the EU (AI pact) that they promise to honour.... (haven't had the time to read through that though, that is if the nitty gritty details are even publicly available).

PS: with apologies to topic starter as this is going waaay off-topic now.

I will "trust" them (and i use that term in the loosest sense possible), if they hardcode the 3 Laws of Isaac Asimov into it.

"I'm sorry, Dave, but i can't do that....."

Which gets us nicely back to the original topic: Protect yourself (and your code) from such "Bugs" as much as you yourself can, and don't rely on other "people" to do everything right
(though, of course we all rely on that in one way or another)

[Warfley]

Probably that People (Programmers) don't use "enough" defensive programming (whichever technique).

It's like driving to a gas-station to refuel your car:
You put the gas pump nozzle into the tank neck (gas-tank being your Buffer)

You don't have Range-check? The Buffer overflows (making a mess on the ground around your car, in the worst case going KABOOM)
You do have Range-Check? The gas pump nozzle switches itself off, because it recognizes the Buffer is full

I mean the main thing with defensive programming techniques is, it can help but you shouldn't need to rely on it. Most programmers are average, thats just how it is. You might have the situation that you can screen your applicants for qualities to only have exceptional developers, but if you are working on some average software development team, most programmers will just be very average. And the average programmer today does not read to much into this stuff. Like everyone who uses their free time and engages in threads like this is already more engaged that the average.

So requiring developers to go to extra length to not make mistakes is already doomed to fail. Also even with the best intentions, people make mistakes. So having tools that make it harder to do mistakes is a way to combat this.

My favorite example for this is probably phone batteries. Phone batteries work best when they are never fully charged or fully decharged. So optimal user behavior would be to unplug the phone when it reaches 80%-90%. But thats not so easy. Apple who is also the device manufacturer and directly earns money by you buying a new phone as often as possible, gives you a notification when 80% is reached. If you have your phone on silence or you are sleeping, you won't notice and overcharge.
Google who only provides the software and doesn't care about how often you buy a new phone on the other hand does something more smart, when you set an alarm in the morning, the phone will stop charging at 80%, and then start again such that it will reach near maximum at the time of the alarm, so once you get up and start using it, it's fully, but it never stays on maximum vor long.

In both cases you can argue if the user of the phone just behaves correctly and always uplugs the phone at 80%-90% they will get the same battery lifetime. But in effect no one actually does that, so the "safety" feature of Android compensates for this, meaning android phones will effectively last longer.

I wouldn't write a security critical program in Pascal, because it's very easy to make mistakes like buffer overflows or similar things, and the language and compiler does not provide many safety features. That said, most software I write is not security critical, so this is not an issue. If you write a desktop application for a single user system, security vulnerabilities are simply not a priority. Simple as that

[TRon]

I will "trust" them (and i use that term in the loosest sense possible), if they hardcode the 3 Laws of Isaac Asimov into it.

That would indeed be a good foundation 

"I'm sorry, Dave, but i can't do that....."

ROFL. thank you for that smile Zvoni.

Which gets us nicely back to the original topic: Protect yourself (and your code) from such "Bugs" as much as you yourself can, and don't rely on other "people" to do everything right
(though, of course we all rely on that in one way or another)

Agreed. Shooting yourself in the foot hurts 

[Zvoni]

I wouldn't write a security critical program in Pascal, because it's very easy to make mistakes like buffer overflows or similar things, and the language and compiler does not provide many safety features. That said, most software I write is not security critical, so this is not an issue. If you write a desktop application for a single user system, security vulnerabilities are simply not a priority. Simple as that

But that's the thing: It doesn't have to do with the chosen language (though there are languages that don't make sense to use in security/safety-critical programs).
See here for "NASA's Power of 10 rule": https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code

[MarkMLl]

Nevermind "defensive programming techniques", which get lost on the wayside.....

Yes, if you are referring to the wiki. One of those things I still have to finish. It is on my list. But what is there is already valuable.

Thaddy, a few weeks ago you said you were going to write some examples for file signing etc... I can't find the thread but did you ever get anywhere with it?

The reason that I ask is that I've repeatedly said in this thread that I think units should be better protected, signed off by an experienced user and so on. There's elements there that can't simply be left to a version control system since I don't think that any of them preserve ownership and file-access attributes ** and since I'm the one wittering about it it would probably be worth my while knowing how somebody skilled in the art would do that sort of thing.

** OK, I suppose OS-level access control wold be adequate if development teams had a rule where all sourcecode was kept in designated locations in a networked filesystem etc. so that only trusted users could manipulate sensitive files, but I can see it getting difficult to manage.

MarkMLl

[BrunoK]

** OK, I suppose OS-level access control wold be adequate if development teams had a rule where all sourcecode was kept in designated locations in a networked filesystem etc. so that only trusted users could manipulate sensitive files, but I can see it getting difficult to manage.

MarkMLl

Also nominate #fakecheckers and #superknlodgable temple guardians ...

[Warfley]

But that's the thing: It doesn't have to do with the chosen language (though there are languages that don't make sense to use in security/safety-critical programs).
See here for "NASA's Power of 10 rule": https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code

But again, if you go into any development team, who does this? I mean if you follow these rules, OOP development is completely out of the picture because it by default breaks 3, 6 and 9. Assertions are disabled by default in the FPC and need to be enabled per unit, so 5 is also usually not followed. ISO pascal actually has the requirement that you always need to read the result of a function, ObjectPascal has ditched that rule because developers found it annoying, which is a good indicator how rarely 7 is followed.

So of these 10 rules, the typical FreePascal codebase already breaks usually with 5 of them, just from the culture that Pascal programming cultivates through it's language design and what the language, compiler and libraries incentivises.

[TRon]

Thaddy, a few weeks ago you said you were going to write some examples for file signing etc... I can't find the thread but did you ever get anywhere with it?

Not being Thaddy but can try help locating the thread. Perhaps one of these ?

• https://forum.lazarus.freepascal.org/index.php/topic,66567.msg510708.html#msg510708
• https://forum.lazarus.freepascal.org/index.php/topic,65976.msg503695.html#msg503695
• https://forum.lazarus.freepascal.org/index.php/topic,65737.msg501327.html#msg501327
• https://forum.lazarus.freepascal.org/index.php/topic,65292.msg499314.html#msg499314
• https://forum.lazarus.freepascal.org/index.php/topic,60981.msg457558.html#msg457558

[BrunoK]

But again, if you go into any development team, who does this? I mean if you follow these rules, OOP development is completely out of the picture because it by default breaks 3, 6 and 9. Assertions are disabled by default in the FPC and need to be enabled per unit, so 5 is also usually not followed. ISO pascal actually has the requirement that you always need to read the result of a function, ObjectPascal has ditched that rule because developers found it annoying, which is a good indicator how rarely 7 is followed.

So of these 10 rules, the typical FreePascal codebase already breaks usually with 5 of them, just from the culture that Pascal programming cultivates through it's language design and what the language, compiler and libraries incentivises.

Spot on with your remarks :-)

A fun one for FPC  in "Assertion (software development)" is

Another popular[3] way of implementing assertions in C is:

static char const static_assertion[ (BOOLEAN CONDITION)
                                    ? 1 : -1
                                  ] = {'!'};

This is for top understandability of the code ...

[Zvoni]

But that's the thing: It doesn't have to do with the chosen language (though there are languages that don't make sense to use in security/safety-critical programs).
See here for "NASA's Power of 10 rule": https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code

But again, if you go into any development team, who does this? I mean if you follow these rules, OOP development is completely out of the picture because it by default breaks 3, 6 and 9. Assertions are disabled by default in the FPC and need to be enabled per unit, so 5 is also usually not followed. ISO pascal actually has the requirement that you always need to read the result of a function, ObjectPascal has ditched that rule because developers found it annoying, which is a good indicator how rarely 7 is followed.

So of these 10 rules, the typical FreePascal codebase already breaks usually with 5 of them, just from the culture that Pascal programming cultivates through it's language design and what the language, compiler and libraries incentivises.

Exactly.
Meaning: It's NOT about relying on some "default"-settings of whatever tool you use, but to actually look into that subject, and what tools are available to deal with it.

Note: Of course, there is still the decision, how far you want to go with it (exactly as you wrote that you don't write critical code)

And i admit, that the NASA-Example is a bit on the "steep" side.
OTOH, you really don't want the door to open on the ISS, because a programmer flipped a sign-bit...

[Thaddy]

Thaddy, a few weeks ago you said you were going to write some examples for file signing etc... I can't find the thread but did you ever get anywhere with it?

Not being Thaddy but can try help locating the thread. Perhaps one of these ?

• https://forum.lazarus.freepascal.org/index.php/topic,66567.msg510708.html#msg510708
• https://forum.lazarus.freepascal.org/index.php/topic,65976.msg503695.html#msg503695
• https://forum.lazarus.freepascal.org/index.php/topic,65737.msg501327.html#msg501327
• https://forum.lazarus.freepascal.org/index.php/topic,65292.msg499314.html#msg499314
• https://forum.lazarus.freepascal.org/index.php/topic,60981.msg457558.html#msg457558

Yes, I am way behind. But there are also so many interests and so few time. Usually it is already in my head and lost the interest to implement it, because there was a more pressing issue to solve. Part of them solved in private messages. But I am behind.

[MarkMLl]

Thaddy, a few weeks ago you said you were going to write some examples for file signing etc... I can't find the thread but did you ever get anywhere with it?

Not being Thaddy but can try help locating the thread. Perhaps one of these ?

Found it

https://forum.lazarus.freepascal.org/index.php/topic,66454.msg511454.html#msg511454

Yes, I am way behind. But there are also so many interests and so few time. Usually it is already in my head and lost the interest to implement it, because there was a more pressing issue to solve. Part of them solved in private messages. But I am behind.

I can assure you I sympathise, and please consider this more of a placeholder than an attempt to apply pressure or demand free work :-)

MarkMLl

[Warfley]

Meaning: It's NOT about relying on some "default"-settings of whatever tool you use, but to actually look into that subject, and what tools are available to deal with it.

Well it kindof is, defaults are very very powerful, because a lot of people never change the defaults. There was recently an article going viral about how a lot of websites still provide ES 5 Javascript code, designed to be compatible with old versions of Internet Explorer, even though IE isn't a thing anymore. This is done by using a transpiler that transpiles modern Javascript code down to older versions, often blowing up the size of the code by orders of magnitude, so a website of a few KB suddenly is a few MB in size. Even more absurd, while shipping libraries that are not ES5 compatible, so it wouldn't work on IE anyway. The reason, the bundling tools still have ES5 transpilation as a default setting, and most developers just go with the default setting.

So FPC not enabling Assertions by default means a lot of people are not working with assertions. Same with range checks, heaptrc, etc.
Another default a lot of people don't change is TypedAddress, this turns the @ operator from an untyped pointer to a typed pointer, which can catch so many errors by typechecking that I'm absolutely amazed how this cannot be a default

Code: Pascal  [Select][+][-]

1. var
2.   i: Integer;
3.   p: PString;
4. begin
5.   p := @i; // not even a warning, if you would dereference p you would have a buffer overflow
6.   {$TypedAddress+}
7.   p := @i; // Error

Also a big influence is the code you are familiar with will influence the code you write. Look at typical Pascal GUI applications, a lot of people just put functions as methods in the Form, even if they don't use any or most of the Form data. Like if you have a function which never uses any of the Methods, Fields, etc. of the form, there is absolutely no reason to put it as a member in the scope of the form.
Why do people do this? Because working inside tha Form class is the typical design of a Pascal GUI application.

I'm always amazed how much new and great language features we have today in Pascal, but if I look at an average Lazarus codebase, it looks pretty much like it could have been writen in Delphi 7 or even earlier. Because most Pascal code is written like this and most pascal developers are familiar with that style of programming, so they write code they are familiar with.
If I look on the other hand at Swift code, Swift has all the features Pascal has plus a few new modern ones, but because Swift is a relatively new Language where all the Examples and Books, etc. show more modern programming styles, you'll very rarely see these bulky 90s/00s style OOP applications like you see in Pascal. Even though it has the exact same constructs that allow for that.

[TRon]

Yes, I am way behind. But there are also so many interests and so few time.
...

Don't worry too much about it Thaddy. However frustrating (for either one or both parties involved), I know the feeling all too well and it seems like there are even less hours in a day the older we get (and more (fun) projects to engage in/with).

Found it

That'll teach me searching for sign while I should have searched for certificate 

Great that you were able to locate it and thx for reporting back that you did.

[Zvoni]

Anyone remembers this?
https://krebsonsecurity.com/2021/11/trojan-source-bug-threatens-the-security-of-all-code/

Code: Pascal  [Select][+][-]

1. var
2.   i: Integer;
3.   p: PString;
4. begin
5.   p := @i; // not even a warning, if you would dereference p you would have a buffer overflow
6.   {$TypedAddress+}
7.   p := @i; // Error

SERIOUSLY?????