On Tue, 30 Sept 2025 at 11:50, Solar Designer <[email protected]> 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;
}
==========================
