linux-kernel - Re: Proper /proc/pid/cmdline behavior when command line is corrupt?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Sep 2006 22:05:35 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Edward Falk <efalk@...gle.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Proper /proc/pid/cmdline behavior when command line is corrupt?

Hi Edward,

>>> that the environment buffer is assumed to immediately follow the
>>> command line buffer.
>> 
>> The environment buffer is not assumed to be there, it is _known_ to
>> come right after the argument string, because that is how the kernel
>> sets it up on execve (for x86 at least).
>
> Is that in a spec somewhere?

http://www.x86-64.org/documentation/abi.pdf#search=%22argv%20envp%20x86%20ABI%22
page 29 figure 3.9 lists the data block in question as "Information
block, including argument strings, environment strings, auxiliary
information", but does not specify it further, like how it is laid out.

What it does mention is "argument pointers" (aka argv[N]) and their
exact position. In fact, right below the figure is the explanation:
"Argument strings, environment strings, and the auxiliary information
appear in no specific order within the information block and they need
not be compactly allocated."

What this means: we are guaranteed that argv[N] is valid, but that not
that the memory range [&argv[0][0] .. &argv[X][Y]] is contiguous. In
fact, if the argument string was not contiguous, but, let's say, have a
map hole, using setproctitle() will inevidently lead to a SIGSEGV.
Probably that is the reason why Linux/glibc do not come with a
setproctitle(3) function. I have taken a look at sendmail, which ships
its own setproctitle (for this very reason), and a source code comment
says it will only use contiguous argv pointers, but I have not looked
at it more closely.

> Otherwise, I would argue that it isn't _known_ to come right after
> the argument string, it just _happens_ to come right after the
> argument string.  This could change in future kernels.

Yes you are right. It may happen that the argument strings come _after_
the environment. Or something even different. In practice that would 
mean that writing over the end of the argument string will write into 
other vital structures, possibly crashing the userspace program. Or if 
not that, it will display garbage in the command line.

What that means for your future patch:

The way how the arg and env strings are laid out are, as far as I can 
tell, defined in fs/binfmt_elf.c:create_elf_tables(). And 
proc_pid_cmdline() depends on this layout, yes. However, since the 
layout is not used anywhere outside the kernel (so says the PDF), there 
should not be a problem. If you modify the layout, make sure it is 
consistent within the kernel. It is unspecified for userspace, and a 
user program accessing this area nonetheless is doing so at its own risk.

Hope this helps.

Regards,
Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/