[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFf+5zio7VxKn_9sDoRc7ap5D8m5LDfWBn5AOd54jLU5Veh4NQ@mail.gmail.com>
Date: Tue, 30 Sep 2025 14:54:58 +0530
From: Amit <amitchoudhary0523@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: How to do secure coding and create secure software
On Tue, 30 Sept 2025 at 11:50, Solar Designer <solar@...nwall.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;
}
==========================
Content of type "text/html" skipped
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
