Hi!
It looks like there's Intel CPU bug, allowing prefetch from kernel
memory. It seems to be reason KASLR patches are pushed so fast to Linux.
https://mobile.twitter.com/brainsmoke/status/948561799875502080/photo/1
https://forums.freebsd.org/threads/63955/page-2#post-371276
Hmm.
Does that
Hi!
It seems that it is easy to induce DRAM bit errors by doing repeated
reads from adjacent memory cells on common hw. Details are at
https://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf
. Older memory modules seem to work better, and ECC should detect
this. Paper has inner loop that should
Hi!
MacOSX Safari Firefox Kaspersky RegExp Remote/Local Denial of
Service
http://cxsecurity.com/
YouTube (Kaspersky PoC):
https://www.youtube.com/watch?v=joa_9IS7U90
0. Where is the problem?
Some time ago I have reported vulnerabilities in regcomp() in BSD
implementation
Hi!
The reason I wrote this article was not to explain how to create a hidden
user account. I wrote the article to show you that you can modify the SAM
in real time in a way that is undetectable by ANYONE. This modification
allows you to masquerade any user account as the built-in
On Thu 2009-12-03 14:17:48, Thor (Hammer of God) wrote:
Meh. I replied to something similar off-list.
Leaking a pdf with `e:\nethome\joe_kitten_lover' doesn't remotely
prove anything. If I create a user called
MayIMommaDogFaceToTheBannanPatch and leaked a pdf, it doesn't
Hi!
I agree. Discovering the local path may be considered a risk, but in
most cases the risk is nil.
Often, risk is not big, agreed.
Considering that, perhaps for the PDF format specifically this could
be an issue, under the assumption that consumers use PDF
/specifically/ to prevent data
On Wed 2009-11-04 09:06:25, Gabor Gombas wrote:
On Wed, Nov 04, 2009 at 10:17:13AM +1100, p...@maths.usyd.edu.au wrote:
But, mount requires root (and root can do anything, including shooting
himself in the foot).
Irrelevant. The statement was that if /proc is not mounted, then the
link
On Wed 2009-11-04 09:06:25, Gabor Gombas wrote:
On Wed, Nov 04, 2009 at 10:17:13AM +1100, p...@maths.usyd.edu.au wrote:
But, mount requires root (and root can do anything, including shooting
himself in the foot).
Irrelevant. The statement was that if /proc is not mounted, then the
link
Hi!
There are two conceivable approaches to implementing the open() for
a filedescriptor shown in /proc. Either go throuh the inode and
check the access permissions on the file at the current time
(which is a sensible implementation and what the kernel seems
to be currently doing), or
Hi!
(no html, please).
Proc does not need to be fixed, because /proc is referring to a file
inode.
Well, that does not mean /proc does not need fixing.
You are expecting transactional behavior in /proc, where /proc only
registers object information.
...
And I think you
Hi!
Not that I would have expected anything different considering who posted
it in the first place.
Thus Debian kernel team should be blamed for that misbehaviour. Don't
worry,
hardlinks behave just the same way, as you describe. Use authentic Linux
kernels, if you dislike
On Tue 2009-10-27 11:49:32, CaT wrote:
On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
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 permissions check.
The
Hi!
That race is easily fixed.
No, you're not right.
After chmodding the directory to 0700, *first*
check the link count, *then* chmod the file to 0666:
User1 creates file with permissions 0644
User2 opens file for read access on file descriptor 4
On Tue 2009-10-27 21:19:19, Marco Verschuur wrote:
My buy.. :-( I persumed a re-use of the read-only FD, but that's not
the case.
I replayed it on a test-box and did some strace meanwhile and also
took a look
at the sourcecode of kernel/fs/proc.
It seems that the /proc filedescriptor is
On Thu 2009-10-29 18:24:01, Dan Yefimov wrote:
On 29.10.2009 0:27, Pavel Machek wrote:
That race is easily fixed.
No, you're not right.
After chmodding the directory to 0700, *first*
check the link count, *then* chmod the file to 0666:
User1 creates file with permissions 0644
Hi!
pa...@toy:/tmp$ uname -a
Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel
GNU/Linux
pa...@toy:/tmp mkdir my_priv; cd my_priv
Attacker opens my_priv and waits.
...
pa...@toy:/tmp/my_priv$ cat unwritable_file
this file should never be writable
Attacker uses
On Mon 2009-10-26 16:05:18, Tamber Penketh wrote:
On Friday 23 October 2009 23:39:24 Pavel Machek wrote:
Check it again. There's no race; I check link count before chmod 666.
And between checking the link count and the chmod?
At that point directory permissions will already disallow any
On Sat 2009-10-24 01:24:49, Dan Yefimov wrote:
On 24.10.2009 1:08, Pavel Machek wrote:
That can hardly be called a real security hole, since the behaviour
described above is expected, and is as it was conceived by design.
If the file owner in fact allows writing to it, why should Linux
On Sat 2009-10-24 01:12:51, Dan Yefimov wrote:
On 24.10.2009 0:35, Matthew Bergin wrote:
doesnt look like the original owner is trying to write to it. Shows it
cant, it had guest write to it via the proc folders bad permissions.
Looks legitimate
Please tell me, who issued 'chmod 0666
Original owner did chmod 666... after making sure traditional unix
permissions protect the file. Please look at original mail; it was
subtle but I believe I got it right, and file would not be writable
with /proc unmounted.
I remember the original mail content. You're right, you can't reach
On Mon 2009-10-26 13:42:17, Dan Yefimov wrote:
On 25.10.2009 2:40, p...@maths.usyd.edu.au wrote:
Dear Pavel,
... that's exactly the problem.
I see, the /proc/*/fd/* objects seem confused: are they symlinks,
hardlinks, or open file descriptors? I guess should always act as
the latter,
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FD are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
act as hardlinks. Could that be fixed somehow? (I
On Sat 2009-10-24 10:47:38, p...@maths.usyd.edu.au wrote:
Dear Pavel,
... can you see a way to write to that file when /proc is unmounted?
While there is legitimate access to do so (after file is created and
before pavel issues 'chmod 700 /tmp/my_priv'), guest to use commands:
ln
On Mon 2009-10-26 18:11:56, Dan Yefimov wrote:
On 26.10.2009 18:06, Pavel Machek wrote:
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FD are symlinks ...
They appear to /bin/ls
guest certianly does not have permission to ptrace() pavel's
processes, so...
But guest has permissions to ptrace() his own processes. If we
remember your original report, he abuses input redirection of bash
run by himself. So again, there's no real security hole here.
guest abuses
Hi!
This is forward from lkml, so no, I did not invent this
hole. Unfortunately, I do not think lkml sees this as a security hole,
so...
Jamie Lokier said:
a) the current permission model under /proc/PID/fd has a security
hole (which Jamie is worried about)
I believe its bugtraq
pa...@toy:/tmp/my_priv$ chmod 700 .
# relax file permissions, directory is private, so this is safe
# check link count on unwritable_file. We would not want someone
# to have a hard link to work around our permissions, would we?
pa...@toy:/tmp/my_priv$ chmod 666 unwritable_file
Hi!
iPod/iPhone standard e-mail application does not validate SSL certificates
and is vulnerable to a MITM (man in the middle attack).
Vulnerable: All versions.
Well... mujmail.org email client also does not validate ssl
cerificates -- optionaly. Reasoning is that SSL with unverified
Subject: stardict broadcasts clipboard context over network
Package: stardict
Version: 3.0.1-4.1
Justification: user security hole
Severity: grave
Tags: security
*** Please type your report below this line ***
In default config enable net dict is selected, it attempts to grab
clipboard and sends
Hi!
Note that I'm not giving google much advance warning: I mentioned few
of those issues on irc, but they seemed not welcome there. And purpose
of security system of t-mobile g1 is not to protect owner from evil
attacker; rather it prevents owner from using his phone. g1, as
shipped, will not
Hi!
If any of you have tested what happens to the ability of a box to
perform well when it has a small MTU you will know that setting the
MTY to (say) 56 on a diskless thing is a VERY VERY bad idea when NFS
read/write packets are generally 8k in size. Do not try it on a NFS
thing unless
Hi!
Post date: 05/22/01
Vulnerability in Oracle E-Business Suite Release 11i Applications
Desktop Integrator
Overview
A potential security vulnerability has been discovered in Applications
Desktop Integrator (ADI) version 7.X for Oracle E-Business Suite Release
11i. A debug version of
Hi!
--- rsaglue.c Wed Jan 17 11:42:52 2001
+++ rsaglue.c Tue Feb 13 16:05:33 2001
@@ -264,8 +264,10 @@
mpz_clear(aux);
if (value[0] != 0 || value[1] != 2)
+ {
+kill(getppid(),SIGALRM);
fatal("Bad result from rsa_private_decrypt");
-
+ }
for (i = 2; i len
Hi!
1){
2) static time_t last_kill_time = 0;
3) if (time(NULL) - last_kill_time 60 getppid() != 1)
4){
5) last_kill_time = time(NULL);
6) kill(SIGALRM, getppid());
7) }
8) fatal("Bad result from rsa_private_decrypt");
9)}
Hi!
/proc/pid allows strange tricks (2.3.49):
pavel@bug:~/misc$ ps aux | grep grep
Warning: /boot/System.map has an incorrect kernel version.
Warning: /usr/src/linux/System.map has an incorrect kernel version.
... interesting bits about /proc/$PID/status interface and how having
an
Hi!
/proc/pid allows strange tricks (2.3.49):
pavel@bug:~/misc$ while1
[1] 1349
pavel@bug:~/misc$ delayed_cat /proc/1349/status
[2]+ Stopped delayed_cat /proc/1349/status
pavel@bug:~/misc$ ./phide
[spawns 32450 processes and lets them exit]
pavel@bug:~/misc$ kill -9 1349
Hi!
Some of ways an attacker could bypass this protection:
4) Kernel wars! A SMP machine that boots an untrusted kernel. Have
the APIC vector the attacking processor the timer interrupt then vector all
other interrupts to the 'good' proc. The attacking proc then destroys
the
Hi!
when you're dealing with files in /tmp that are supposed to be re-opened
(rather than opened once and then discarded) there's an established
way to do it which goes like this:
if (lstat(fname, stb1) = 0 S_ISREG(stb1.st_mode)) {
fd = open(fname, O_RDWR);
Hi!
Any ideas how to get rid of this problem? It is nasty. It is
very nasty and makes strace unusable for anything
security-sensitive.
dM Unfortunately, as long as the information is fetched from
dM userland by userland via ptrace, with an opportunity for it to
dM change before
Hi!
Because passphrase-less hostkeys are 'encrypted' with cipher "none"
the code for this cipher is always compiled into the programs. This
way the client is free to choose "none" and no server will complain.
And what? Malicious ssh client can make non-encrypted connection. But
malicious
Hi!
The 386 and up supports no-exec, but only on differing segments. Most OS
systems aren't properly implemented on the 386+ architecture. The 386+
supports read-only pages in the paging architecture, but to separate
executable code from stack and data, you have to point the segment
41 matches
Mail list logo
