ith
mode 0111 (d--x--x--x) as you can't open() the directory (O_RDONLY
fails with EPERM, anything else fails with EISDIR).
--
Glynn Clements
chmod'ed down later. It needs to be created with the
restrictive permissions from the outset.
--
Glynn Clements
ser limited the amount of memory which
could be used by e.g. JavaScript (although for Firefox, you would
probably want the limit to only be applied to "external" JavaScript,
given that much of the browser itself is written in JavaScript).
--
Glynn Clements <[EMAIL PROTECTED]>
our bank or a CA's server that might count as a
> feature :-)
The major problem I can see is that it's not at all uncommon to have
dozens or even hundreds of hostnames all resolve to a single IP
address belonging to a shared server. Requesting a PTR record for that
IP address typi
ed to whatever features the kernel
provides. If you limit yourself to bare-bones POSIX (no capabilities,
or extensions such as SELinux or RSBAC), the set of features is rather
lacking in this regard.
--
Glynn Clements <[EMAIL PROTECTED]>
ect against a shell-injection bug
in Windows' URI handler is a workaround (mitigation strategy), not a
fix.
--
Glynn Clements <[EMAIL PROTECTED]>
t PDEATHSIG would be subject to the same
kind of restrictions as kill() or F_SETOWN etc. But in this case, the
"sender" is incorrectly determined as the EUID at the point that the
process dies rather than the point that prctl() was called. Recording
the actual "initiator" probably isn't feasible, so clearing PDEATHSIG
on setuid exec() is probably the only viable solution.
--
Glynn Clements <[EMAIL PROTECTED]>
rally impossible. Once spawned setuid root binary that will
> send a signal while dying, you have no control over the moment the signal is
> being sent at. The exploitation scenario for this bug is a bit artificial.
IMO, privilege elevation is a security issue regardless of whether or
not one can provide a "useful" scenario immediately upon the issue
becoming known.
--
Glynn Clements <[EMAIL PROTECTED]>
le.
Sending asynchronous signals to setuid/setgid children is supposed to
be impossible, and that restriction is considered a security
mechanism.
> > > > Moreover, I would suggest that exec()ing a suid/sgid binary should
> > > > reset *everything* which is not explicitly specified as being
> > > > preserved.
> > >
> > > Specified with what?
> >
> > POSIX, XPG, SUS.
>
> I got you. I just thought you want to reset everything successively including
> sigmasks and open files :-) .
No. I'm suggesting that it should be possible for a setuid/setgid
program to *exhaustively* sanitise (or at least validate) its
operating environment.
--
Glynn Clements <[EMAIL PROTECTED]>
r that is closed for this reason,
file locks are removed as a result of the close as described in
close(). Locks that are not removed by closing of file descriptors
remain unchanged.
> Does blocked signal bitmap fall into it?
Yes.
>From the above link:
The initial thread of the new process shall inherit at least the
following attributes from the calling thread:
* Signal mask (see sigprocmask() and pthread_sigmask())
* Pending signals (see sigpending())
> What exactly are you going to reset?
Everything which is not specified as being preserved. Which means
every non-standard extension that programmers won't have heard of and
won't be expecting to have to manually reset.
--
Glynn Clements <[EMAIL PROTECTED]>
: code which isn't
specifically written for Linux isn't going to take steps to mitigate
this issue (e.g. reset the parent death signal).
But the suggestion that this should be reset on exec() (at least for a
suid/sgid binary) is sound, IMHO.
Moreover, I would suggest that exec()ing a sui
ecure system would need to ensure that the user specifically
authorises the transfer of amount X to recipient Y, and not merely
some unspecified transaction.
Eliminating trust in the user's PC would require that the significant
details of the transaction are passed to the secure device, which
realistically requires a better communication channel than a keypad.
--
Glynn Clements <[EMAIL PROTECTED]>
oading a malicious
file from the internet.
I don't think that remote X clients are an issue; the last time I
checked, the driver in question was only used for direct rendering,
which requires a local X client, while indirect rendering uses the
built-in software renderer.
--
Glynn Clements <[EMAIL PROTECTED]>
ng would be represented in its
"natural" form, i.e. it wouldn't contain any language "syntax".
Apart from being more robust, such a language should also make life
easier for the application developer, as they don't have to implement
their own equivalents. Even programmers who don't understand the
security issues will typically have to deal with many of these issues
in order to get their code to simply work.
--
Glynn Clements <[EMAIL PROTECTED]>
posession of "hacking
tools", which will make even legitimate pen-testing difficult. It may
not be possible to simply outsource pen-testing to a country where
such tools are legal (e.g. due to laws restricting the transfer of
sensitive data abroad).
--
Glynn Clements <[EMAIL PROTECTED]>
only accepted for the server
> setting the cookie.
>
> We are investigating ways to improve on this method, but as far as I can
> tell, any improvement will require a coordinated effort by all the gTLD
> and ccTLD registries.
Any improvement will require that browsers only pass cookies to
domains which are explicitly permitted by the setter, and pass the
setter domain to all recipients alongside the cookie. IOW, a protocol
change. Anything else is papering over the cracks.
--
Glynn Clements <[EMAIL PROTECTED]>
e DOS box" - if the former, then GetFileType is sadly of no
> assistance.
Can anyone shed any light upon whether the act of opening a device
under Windows can have undesirable side effects?
--
Glynn Clements <[EMAIL PROTECTED]>
In general, the two-byte sequences have the (binary) form:
110x 10xx
The range 0-127 (which must use the single-byte form instead)
corresponds to:
110x 10xx
Hence, any sequence beginning with 1100 (0xC0) or 1101 (0xC1)
is illegal.
--
Glynn Clements <[EMAIL PROTECTED]>
directories are
>used to store temporary files.
Recent versions of XEmacs honour $TMPDIR, so there shouldn't be any
need to use public directories.
> 3.3. Problem
>
>Functions like read-passwd do not clear the the history of
>recently typed keys. In fact, th
If the code and stack/data segments do overlap, then it doesn't matter
whether or not the stack/data segment is executable. You simply write
to the stack/data segment then execute the code via the code segment
(return addresses are implicitly relative to the code segment).
--
Glynn Clements <[EMAIL PROTECTED]>
sn't
that was commonly used for 16-bit x86 development).
Also, using segmentation pretty much guarantees that your OS cannot be
made to run on anything other than the x86 architecture (which is
about the worst of the bunch; no sane person would use x86 if wasn't
for the compatibility issues).
--
Glynn Clements <[EMAIL PROTECTED]>
by shared mmap()'ing a few large files between pairs of processes. (All)
mmap() is potentially less serious as the memory will be released if
the processes are killed.
--
Glynn Clements <[EMAIL PROTECTED]>
22 matches
Mail list logo