Re: How to do secure coding and create secure software

[Amit <amitchoudhary0523 () gmail com>]

On Tue, 30 Sept 2025 at 11:50, Solar Designer <solar () openwall com> wrote:

> A correction:
>
> On Tue, Sep 30, 2025 at 07:23:52AM +0200, Solar Designer wrote:
> > A malicious HTTP client connects to the HTTP server and requests an URL
> > corresponding to the CGI script.  It uses the PUT method.  It passes a
> > header named GET_SHELL_FUNCTION with a value that defines a shell
> > function body, which ends up injected and executed.
>
> This should be PUT_SHELL_FUNCTION in place of GET_SHELL_FUNCTION.
>
> On Tue, Sep 30, 2025 at 01:02:01AM -0500, Jacob Bachmeyer wrote:
> > On 9/30/25 00:23, Solar Designer wrote:
> > > [...]
> > > So is the vulnerability in the shell, like Shellshock was determined to
> > > be?  [...] the shell maintainers may well dispute this CVE on
> > > such grounds as well as because the shell worked exactly as documented.
> > > [...]
> >
> > Small nit here:  Shellshock was clearly a vulnerability in Bash and I am
> > unsure if the way Bash exports shell functions was documented at all.
>
> I agree, which is why I invented a different and documented alternative
> for the sake of this example.
>
> > If presented with an environment variable value having the correct form
> > for a shell function, but containing more text than the body of the
> > function, Bash would immediately execute the trailing text as commands
> > while importing the shell function from the environment.  That was
> > Shellshock.
>
> Yes, there were multiple Shellshock-related code issues in bash, and
> several CVEs were rightly assigned against bash.  No arguing about that.
> Also, the proper Shellshock was exposed as a vulnerability by far not
> only through HTTP servers, since it parsed variables of any names.
>
> My point is that a similar documented and correctly implemented feature
> could also become a vulnerability in some interactions.
>
> Now let's be winding this thread down, please.


Definitely, let's wind down this thread.

My final point: My whole idea was that a normal programmer doesn't know
that if all functions (including main) are secure then the software will be
secure. And the programmer should only worry about making his/her functions
secure and not think about the whole software and the programmer doesn't
need to think about side-channel attacks, buffer-overflow attacks, etc.
Basically, I have narrowed down the security of the software to the
functions. And that's why I wrote that article to educate
programmers/people.

But it looks like people here think that my article is useless. It is fine
with me. I know that not everyone in the world will agree with me.

Developers (whether closed source or open source) don't take input
validation seriously - in glibc/POSIX, many functions don't validate the
inputs and cyberattackers have taken advantage of glibc vulnerabilities in
the past (like buffer overflow, etc.). It is also very easy to crash
glibc/POSIX functions.

By the way, I never said that a function should crash if an input is
invalid. Although, I didn't say it explicitly, but I return an error if
some input is invalid.

And as far as losing performance because of input validation is concerned,
I have done few experiments with glibc and I validated qsort() function
arguments (4 in number) and the performance degradation was only 2.61%.

I definitely want to wind down this thread.

Below is an example of the code that I write:

==========================
int tl_add_menu_item(struct tm_container *tc_ptr, const char
*menu_item_text,
                     FUNC_PTR func_ptr, void *private_data)

{



    struct menu_item *mi_ptr = NULL;

    size_t len = 0;



    if (!tc_ptr) {

        return TL_TC_PTR_IS_NULL;

    }



    if (!menu_item_text) {

        return TL_MENU_ITEM_TEXT_IS_NULL;

    }



    if (!func_ptr) {

        return TL_FUNC_PTR_IS_NULL;

    }



    if (tc_ptr->number_of_menu_items_added ==

                                    tc_ptr->total_number_of_menu_items) {

        return TL_NO_MORE_MENU_ITEMS_CAN_BE_ADDED;

    }



    len = strnlen(menu_item_text, TL_MAX_MENU_ITEM_TEXT_SIZE);



    if ((len < 1) || (len == TL_MAX_MENU_ITEM_TEXT_SIZE)) {

        return TL_MENU_ITEM_TEXT_SIZE_IS_OUT_OF_BOUNDS;

    }

==========================