manual page
> documented and setuid root program must know which file descriptor should be
> closed to prevent that, which is of course not possible. The only cure here is
> closing every file descriptor above 2, but that is still insufficient, since
> fcntl() might be issued on file descriptors from 0 to 2.
The fcntl(2) manpage says:
Sending a signal to the owner process (group) specified by
F_SETOWN is subject to the same permissions checks as are
described for kill(2), where the sending process is the one that
employs F_SETOWN (but see BUGS below).
Hello,
Is this internal or external thus do you need to be logged in? I tested external/internal and nothing it appears to just dump it out as a missing directory or manpage.
"Could not open /usr/man/man3/%3Cscript%3Ealert(LeZr)%3C/script%3E.3"
Also I believe you meant to place x3 instead of x after frontend? if not it still just says manpage not found.
I tested this out on 11.18.3-STABLE build 21703.
Regards
> hardlink to that file in a unrestricted location, what would you say?
>
> Do your homework and test it. You can't create the hardlink -
> the link(oldpath, newpath) call will fail with EACCES if
> search permission is denied for any directory in oldpath or
> newpath. Documented in the manpage, and I just tested and verified it.
>
It's creating the hardlink (or setting the fd in /proc) before the directory is locked down to user-only permissions. You will be allowed access to whatever the file allows, despite what the directory permissions are. This seems expected to me, since the files will be the same inode. If I'm following this correctly it comes down to some distributions treating /proc/*/fd/* as hardlinks, for whatever reason.
>
The "data_max" signed integer variable will be set to -1 at
cgiutil.c:55. The "data" character array is assigned the pointer
returned from "malloc( -1 + 1 )" on the following line (56). Note
that the Linux man page for malloc(3) (dated 2007-09-15) says:
"If [the argument] is 0, then malloc() returns either
NULL, or a unique pointer value that can later be
successfully passed to free()."
3) prints a warning if it has to fall back to using time()
Users of Microsoft Windows or other target platforms that lack /dev/urandom
might want to improve on this approach with appropriate APIS such as
RtlGenRandom on Windows. Also, the patch provides no updates to the htpasswd
man page documentation.
History:
Vulnerability reported via vendor's bug tracking database, and source
code patch made available, on 25 January 2008.
Ruby Gnome2 is a project to provide GTK2 bindings to ruby scripts so you can write GUI code in less time. There is a format string vulnerability in Gtk::MessageDialog(). This design flaw does not
allow for a user generated string to be safely sent to this function.
It is really just an API to the GTK2 function gtk_message_dialog_new() Ruby/Gnome2 does not properly use a format specifier for the message
variable in ruby-gnome2-all-0.16.0/gtk/src/rbgtkmessagedialog.c as requested by the Gtk man page for this function.
...
w = gtk_message_dialog_new(NIL_P(parent) ? NULL : GTK_WINDOW(RVAL2GOBJ(parent)),
RVAL2GFLAGS(flags, GTK_TYPE_DIALOG_FLAGS),
RVAL2GENUM(type, GTK_TYPE_MESSAGE_TYPE),
It is possible to specify command line switches for the keyword program
in place of the argument. The gravity of this vulnerability depends on
the keyword program selected. GNU man, the default keyword program in
many installations, supports for example the ``--pager'' option (cf.
the GNU man(1) manual page). This allows arbitrary command execution.
3.2. Tag Lookup -- the ``Control-]'' and ``g]'' Commands
Insufficient sanitization of an Ex command argument allows specifying
> * Dan Yefimov <dan@ns15.lightwave.net.ru> [2007-08-17 05:27 +0400]:
> > BTW, SIGKILL and SIGSTOP can be issued by an O_ASYNC file I/O also (look in
> > fcntl(2) at F_SETSIG section). If you use F_SETSIG for sending SIGKILL or
> > SIGSTOP, there's nothing to be done with that - that behaviour is well
>
> Looking in that man page I see:
> F_GETSIG and F_SETSIG are Linux-specific.
>
And we consider Linux too. But anyway, they're unexploitable since signals set
with F_SETSIG are subject to usual permission checks.
--
> It is possible to specify command line switches for the
> keyword program in place of the argument. The gravity of
> this vulnerability depends on the keyword program selected.
> GNU man, the default keyword program in many installations,
> supports for example the ``--pager'' option (cf.
> the GNU man(1) manual page). This allows arbitrary command execution.
As does setting PAGER in the environment before vim starts, which is an equally plausible attack.
Schmidt did accidentally discover an issue with unescaped characters and the K command - specifically with Visual-K and an unconventional setting of keywordprg, used in a manner for which it was not intended (selecting a URL and using K to pass it to a browser). See Minr's [1]. So it's not impossible for someone to encounter this bug while operating in a manner they think is sensible.
* Dan Yefimov <dan@ns15.lightwave.net.ru> [2007-08-17 05:27 +0400]:
> BTW, SIGKILL and SIGSTOP can be issued by an O_ASYNC file I/O also (look in
> fcntl(2) at F_SETSIG section). If you use F_SETSIG for sending SIGKILL or
> SIGSTOP, there's nothing to be done with that - that behaviour is well
Looking in that man page I see:
F_GETSIG and F_SETSIG are Linux-specific.
Nicolas
--
exclude_from, and filter and read or write hidden files via (1)
symlink, (2) partial-dir, (3) backup-dir, and unspecified (4) dest
options. (CVE-2007-6200)
This update fixes these issues. It is recommended users (specially
system and network administrators) read the manpage about the
introduced munge symlinks feature.
This update also upgrades rsync to version 2.6.9 for all Mandriva
Linux versions earlier than 2008.0.
_______________________________________________________________________
A quick test confirms PCRE does not backtrack when it evaluates regular
expressions like ^(a+)*$ and the rest of your "real examples of ReDos"
(because their ambiguity is optimized away) and something rather
convoluted like ^((a{1,2}){1,2}){1,10}$ is needed to trigger
backtracking. See "Backtracking" in perlre manpage.
--
Pavel Kankovsky aka Peak / Jeremiah 9:21 \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /
> > documented and setuid root program must know which file descriptor should be
> > closed to prevent that, which is of course not possible. The only cure here is
> > closing every file descriptor above 2, but that is still insufficient, since
> > fcntl() might be issued on file descriptors from 0 to 2.
>
> The fcntl(2) manpage says:
>
> Sending a signal to the owner process (group) specified by
> F_SETOWN is subject to the same permissions checks as are
> described for kill(2), where the sending process is the one that
> employs F_SETOWN (but see BUGS below).
and config file:
--- CUT ---
// Sample pdnsd configuration file. Must be customized to obtain a working pdnsd setup!
// Read the pdnsd.conf(5) manpage for an explanation of the options.
// Add or remove '#' in front of options you want to disable or enable, respectively.
// Remove '/*' and '*/' to enable complete sections.
global {
perm_cache=1024;
Unless the chroot feature of nostromo is used, any file in the system
that is readable with the runtime permissions of nostromo can be
accessed.
A peculiarity of nostromo is the handling of CGI scripts. Citing the
manual page, "CGIs are recognized by the file world executable flag".
Therefore, any program or script, that is executable by the system user
nostromo runs as, will be executed when one tries to access it through
directory traversal. Any data received in the body of a HTTP POST
request will be sent to standard input of executed CGI scripts.
for symlink attacks.
Background
==========
TkMan is a graphical, hypertext manual page and Texinfo browser for
UNIX.
Affected packages
=================
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=1
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
Number of processes running now: 0
090620 01:53:52 mysqld restarted
090620 1:53:52 InnoDB: Started; log sequence number 0 4876777
>> It didn't in fact change anything. If the guest created hardlink to that file in
>> a unrestricted location, what would you say?
>
> Do your homework and test it. You can't create the hardlink - the link(oldpath,
> newpath) call will fail with EACCES if search permission is denied for any
> directory in oldpath or newpath. Documented in the manpage, and I just tested
> and verified it.
>
Good boy. However, there wasn't worth both citing well known facts to me and
testing them. Remember the scenario from the original mail and try finding a
window, during which creating a hardlink would still work thus evading directory
>> I do not think mounting /proc should change access control semantics.
>>
>It didn't in fact change anything. If the guest created hardlink to that file in a unrestricted location, what would you say?
Do your homework and test it. You can't create the hardlink - the link(oldpath, newpath) call will fail with EACCES if search permission is denied for any directory in oldpath or newpath. Documented in the manpage, and I just tested and verified it.
Fact is, directory permissions are relevant in Unix. Despite it's permissions, under the Unix access permission semantics the file is unwriteable for anyone but the owner, and this bug pokes a hole into that.
> > signal it sends. For details look at check_kill_permission() and
> > group_send_sig_info() in kernel/signal.c and reparent_thread() in
> > kernel/exit.c in the kernel source tree (version 2.6.22).
>
> Dan, could you take a closer look at what setuid(0) does? In the beggining
> of setuid manual page you can read that:
>
> setuid sets the effective user ID of the current process.
> If the effective userid of the caller is root, the real
> and saved user ID's are also set.
>
|
