| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Apache's mod_rewrite module can be made to write one zero byte in an
arbitrary memory position outside of a char array, causing DoS or
possibly buffer overflows.
The function lookup_map_dbmfile() in modules/mappers/mod_rewrite.c
copies data from a DBM file to the char array buf in a _secure_ manner,
but it zero-terminates the array afterwards in an _insecure_ manner. If
the key that is looked up has an n bytes long value, a zero byte will be
written in the memory position n bytes from the start of the char array
buf.
exploiting would require enabling dbm for mod_rewrite and getting it to use
a malicious dbm file.
reported by Ulf.Harnhammar.9485@student.uu.se
fix by me
ok otto, deraadt
|
|
|
|
the client. Make UseCanonicalName socket port aware.
ok henning@
|
|
|
|
when enabled but no explicit CookieName is set.
From: Apache CVS
ok henning@
|
|
Reject responses from a remote server if sent an invalid (negative)
Content-Length. [Mark Cox]
|
|
*) Fix buffer overflow in "SSLOptions +FakeBasicAuth" implementation
if the Subject-DN in the client certificate exceeds 6KB in length.
(CVE CAN-2004-0488).
*) Handle the case of OpenSSL retry requests after interrupted system
calls during the SSL handshake phase.
*) Remove some unused functions.
|
|
by using a AuthNonce secret.
CAN-2003-0987
ok henning@
|
|
could make it easier for attackers to insert those sequences into terminal
emulators containing vulnerabilities related to escape sequences.
CAN-2003-0020
ok henning@
|
|
ok drahn@ henning@
|
|
to produce a double, snprintf()ing that into a buffer and then
converting the string to an int with atoi().
ok millert@ henning@
|
|
ok millert@ henning@
|
|
modules, From: Robert McMeekin <rrm3@rrm3.org>
|
|
|
|
reasons for this, quite a few of them technical, and not all of them
in response to Intel's broken ia32e crud. The gcc toolchain stays at
x86_64 for now.
|
|
|
|
|
|
a etoh diff
|
|
|
|
|
|
ok henning@
|
|
ok henning@
|
|
(e.g. 192.168.1.1) where parsed incorrectly on sparc64.
It only affected IP addresses with no netmask definition.
The cause of this was:
a) use of the wrong type -- unsigned long instead of a 32bit value
b) implicit casts from int to unsigned long with sign extension
While doing that fix also some other obvious bugs.
from claudio jeker
|
|
|
|
|
|
|
|
|
|
ok brad@
|
|
|
|
and a short description what it does
result of a conversation with nick@ and Diana Eichert
|
|
|
|
SECURITY: CAN-2003-0542 (cve.mitre.org)
Fix buffer overflows in mod_alias and mod_rewrite which occurred if
one configured a regular expression with more than 9 captures.
[André Malo]
ok markus@
|
|
ok deraadt@
|
|
ok deraadt@
|
|
ok henning@
|
|
Sandor Palfy <netchan@cotse.net>
|
|
|
|
secondary groups get initialized as well.
ok beck@ deraadt@
|
|
|
|
|
|
ok markus@
|
|
noriced by theo
|
|
|
|
|
|
|
|
introduced with 1.3.28:
Apparently there has been a regression in 1.3.28 from 1.3.27 whereby
CGI scripts are getting left around as zombies when suexec is in use,
apparently because of a change in src/main/alloc.c that altered the
behavior when sending SIGTERM to a child process. With suexec, the
SIGTERM at line 2862 will fail not because the subprocess is dead already
but because the httpd uid has no permission to term the cgi process, which
is running as some other user.
fix by Ralf S. Engelschall:
That is, we don't have to check for the return value of ap_os_kill()
and especially not check for ESRCH, because we _HAVE_ to waitpid() for
it anyway (because it's our child and it either is already terminated
and is waiting as a zombie for our waitpid() or it is still running).
Under Unix it cannot be that a (non-detached in the sense of BSD's
daemon(3)) child of a process just does no longer exists as long as
the parent still exists and as long as the parent still has not done
waitpid() for the child. So ESRCH cannot happen in our situation and the
patch we currently use is fully sufficient. Both are at least portable
enough for Unix, of course...
|
|
|
|
|
|
|
