Re: [Full-disclosure] Re: readdir_r considered harmful
[EMAIL PROTECTED] wrote: ... Had they done so, we would never have had to use readdir_r() and progammers would not have introduced bugs in the (mis)use of pathconf, over allocating, etc. I would be interested in seeing any real-world use of readdir_r() in a context where readdir_r() is required (multiple threads reading from a single DIR *). Consider the following situation(I'm not sure if anyone actually does this): 1) You have a spool directory containing a large number of files, each which represents a task to process. 2) You have a number of worker threads. Each worker thread reads a file from the global DIR*, and then opens and reads the file for processing(and then loops on 2). Of course, you could always just put a mutex around every call to readdir(), and copy the filename somewhere safe, or you could invent a signalling system to ask one thread to do all the readdir()s. Whether this makes sense depends on how much of readdir_r has to be spent inside a global mutex/spinlock anyway, and how long the processing part takes compared with the readdir() part. Andrew
Re: [Full-disclosure] Re: readdir_r considered harmful
In practice, you're correct. In theory, however, consider the following code path. THREAD 1 THREAD 2 ---- DIR *d1 = opendir(dir1); DIR *d2 = opendir(dir2); dent1 = readdir(dir1); dent2 = readdir(dir2); use(dent1); In most implementations, dent1 != dent2. HOWEVER, there is no guarantee that they will not both point to the same statically allocated buffer, and some implementations may do so. For example, this is why ctime_r exists: ctime returns a pointer to a statically allocated buffer, and hence is not thread safe. The standard actually guarantees that the static storage is associated with the specific directory STREAM. So a system on which dent1 and dent2 point to the same buffer and reads from one stream affect the buffer returned by reads from another stream are not POSIX compliant. See: http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html The pointer returned by readdir() points to data which may be overwritten by another call to readdir() on the same directory stream. This data is not overwritten by another call to readdir() on a different directory stream. But is also goes on to say: The readdir() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. which is the one thing I like POSIX to fix for thread safe implementations. Casper
Call For Papers
Call For Papers 18th Annual FIRST Conference Baltimore, MD June 25-30, 2006 The Forum of Incident Response and Security Teams (FIRST, http://www.first.org/) is a global organization dedicated to bringing together computer security incident response teams (CSIRTs). The annual FIRST conference not only provides a setting for participants to attend tutorials and hear presentations by leading experts in the CSIRT community, it also creates opportunities for networking, collaboration, and sharing of technical information. Equally important, this conference enables the attendees to meet with their peers and build trusted relationships. FIRST continues to enjoy a steady increase in membership internationally and is represented by teams from government, commercial and research/educational communities. FIRST conference participants include not only CSIRT staff, but also IT managers, network and system administrators, software and hardware vendors, security solutions providers, telecommunications organizations, ISPs, and general computer and network security personnel. FIRST conferences cover a number of different areas such as (but are not limited to): * advanced techniques in security incident prevention, detection and response. * latest advances in computer and network security tools. * shared views, experiences, and resolutions in the computer security incident response field. The conference is a five-day event, comprised of two days of Tutorials, three days of Plenary sessions focused on either Business or Technical issues. These include paper presentations, keynote speeches and/or panel discussions. The theme for the 2006 conference is Sharing Intelligence in Global Response working smarter and sharing knowledge in this environment, finding ways to further our initiatives on collaborative and cooperative approaches to find solutions to the problems we face in computer and network security incident response. Conference presentations are generally 30-45 minutes in length, including any QA session. The conference language is English. The program committee welcomes original contributions on network security for refereed paper presentations, tutorials, invited talks and panel sessions, and can include topics such as: * Incident Response * Response Team Operational Issues and Tools * Response Team Cooperation, Methods and Techniques for information sharing, collaboration and discussion of legal issues * Traffic monitoring, detection, and eal-time situational awareness * Vulnerability Handling * Software assurance * New Technologies * New Vulnerabilities * Risk Assessment and Information Analysis * New threats and incident trends * Lessons learned from establishing National Teams Process of Selection The program committee will evaluate papers, tutorials, and panels based on quality and relevance. All submissions are held in confidence prior to publication in the proceedings. Submissions received after the deadline (see Important Dates below) will not be considered unless an extension has been granted by the program chair. Where employer, client, or government authorization is needed, it is the responsibility of the author(s) to obtain such authorization prior to submitting the final materials. Accepted papers will be presented by their author(s) and will be published in the conference proceedings. The proceedings are provided free of charge to conference attendees. The papers will also be published on the FIRST Members portion of the website. These are restricted to the FIRST membership until 01 January 2007, after which time the documents will be publicly accessible on the FIRST website. Copyright FIRST requires a non-exclusive copyright license for all the papers presented at the conference and for the presentation materials. This includes distribution on the conference CD-ROM and the FIRST website. Submissions Tutorial Submission Two tutorial tracks are planned. Tutorials should have either a technical or business/management focus. Technical tutorials should be targeted at a technical audience consisting of IT or security professionals. Business tutorials should be targeted for an audience of directors, managers, policy makers, legal and law enforcement staff, and IT professionals who may have managerial responsibilities. Ideas for subject matter may be pulled from the example topics listed above. Tutorials may be a half or full day in length and can cover topics either at an introductory or advanced level. All tutorial submissions will be handled electronically. Authors should email the completed submission form (available on the FIRST website) to: [EMAIL PROTECTED] Paper Submission Authors are invited to submit papers in PDF format (RTF and HTML are also accepted). The length should not exceed 12 pages typeset in a 12-point font. A detailed extended
MDKSA-2005:205 - Updated clamav packages fix multiple vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2005:205 http://www.mandriva.com/security/ ___ Package : clamav Date: November 7, 2005 Affected: 10.1, 10.2, 2006.0, Corporate 3.0 ___ Problem Description: A number of vulnerabilities were discovered in ClamAV versions prior to 0.87.1: The OLE2 unpacker in clamd allows remote attackers to cause a DoS (segfault) via a DOC file with an invalid property tree (CVE-2005-3239) The FSG unpacker allows remote attackers to cause memory corruption and execute arbitrary code via a crafted FSG 1.33 file (CVE-2005-3303) The tnef_attachment() function allows remote attackers to cause a DoS (infinite loop and memory exhaustion) via a crafted value in a CAB file that causes ClamAV to repeatedly scan the same block (CVE-2005-3500) Remote attackers could cause a DoS (infinite loop) via a crafted CAB file (CVE-2005-3501) This update provides ClamAV 0.87.1 which corrects all of these issues. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3239 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3303 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3500 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3501 ___ Updated Packages: Mandriva Linux 10.1: 2c8a8799bda10e6695bc2ee6d1f76936 10.1/RPMS/clamav-0.87.1-0.1.101mdk.i586.rpm 6e31a793ae79cb40064c52fe64c11155 10.1/RPMS/clamav-db-0.87.1-0.1.101mdk.i586.rpm e58b5816114176f8c4ff7984e5a8295e 10.1/RPMS/clamav-milter-0.87.1-0.1.101mdk.i586.rpm d1604de5950ed1060c327cea79060546 10.1/RPMS/clamd-0.87.1-0.1.101mdk.i586.rpm ca64314db8e86e57ba76c1c569058122 10.1/RPMS/libclamav1-0.87.1-0.1.101mdk.i586.rpm c99ffb5b095e8e83acd218b679435c03 10.1/RPMS/libclamav1-devel-0.87.1-0.1.101mdk.i586.rpm ecddf8805cbae3e8f52719d97af50290 10.1/SRPMS/clamav-0.87.1-0.1.101mdk.src.rpm Mandriva Linux 10.1/X86_64: f8df2fa1ec1538d3c691462ece32459e x86_64/10.1/RPMS/clamav-0.87.1-0.1.101mdk.x86_64.rpm c8d3c45be5696671b4e968d923048250 x86_64/10.1/RPMS/clamav-db-0.87.1-0.1.101mdk.x86_64.rpm 5a1d8f5bf844b9d17fc6daeac3d9980f x86_64/10.1/RPMS/clamav-milter-0.87.1-0.1.101mdk.x86_64.rpm f29cf94d9bf5aed77fed89b62c3a31bd x86_64/10.1/RPMS/clamd-0.87.1-0.1.101mdk.x86_64.rpm af1d5f8be95f46fee78d441a9a9ef1d5 x86_64/10.1/RPMS/lib64clamav1-0.87.1-0.1.101mdk.x86_64.rpm f6dd47c525bfda31472aeeb130b44b04 x86_64/10.1/RPMS/lib64clamav1-devel-0.87.1-0.1.101mdk.x86_64.rpm ecddf8805cbae3e8f52719d97af50290 x86_64/10.1/SRPMS/clamav-0.87.1-0.1.101mdk.src.rpm Mandriva Linux 10.2: 3da7284615847be748e0ee755ab56963 10.2/RPMS/clamav-0.87.1-0.1.102mdk.i586.rpm cbe42a738a4008a559c56e51b9a6fe47 10.2/RPMS/clamav-db-0.87.1-0.1.102mdk.i586.rpm 1778a62fe729d77234ef1c1bde7f3cd0 10.2/RPMS/clamav-milter-0.87.1-0.1.102mdk.i586.rpm ae2d916c80f50f5386bd70e06c0b2fd2 10.2/RPMS/clamd-0.87.1-0.1.102mdk.i586.rpm d08c87436e20faf977f1ad059bc233b4 10.2/RPMS/libclamav1-0.87.1-0.1.102mdk.i586.rpm 74ee8b845b1c7a41ccdbf1c1e04591a5 10.2/RPMS/libclamav1-devel-0.87.1-0.1.102mdk.i586.rpm dd72cdbb564bf27c8f745b198cdbc99f 10.2/SRPMS/clamav-0.87.1-0.1.102mdk.src.rpm Mandriva Linux 10.2/X86_64: 10de2a9bf399f3a1c93732a9ef664664 x86_64/10.2/RPMS/clamav-0.87.1-0.1.102mdk.x86_64.rpm 0c87818d634084a023584d1c7146093f x86_64/10.2/RPMS/clamav-db-0.87.1-0.1.102mdk.x86_64.rpm 9ed0aaf9bf139c11a6641b073c35aecd x86_64/10.2/RPMS/clamav-milter-0.87.1-0.1.102mdk.x86_64.rpm 3c2d858b3fb039c735cb0cc0cb109e92 x86_64/10.2/RPMS/clamd-0.87.1-0.1.102mdk.x86_64.rpm 6b9d20e975ed97fc68f812189bfb86e8 x86_64/10.2/RPMS/lib64clamav1-0.87.1-0.1.102mdk.x86_64.rpm 4515067e6c33151d6555ed217914e696 x86_64/10.2/RPMS/lib64clamav1-devel-0.87.1-0.1.102mdk.x86_64.rpm dd72cdbb564bf27c8f745b198cdbc99f x86_64/10.2/SRPMS/clamav-0.87.1-0.1.102mdk.src.rpm Mandriva Linux 2006.0: 64044555942d783f59191af6bb051fe6 2006.0/RPMS/clamav-0.87.1-0.1.20060mdk.i586.rpm 3b090dc5a8a700c8dd58478201041384 2006.0/RPMS/clamav-db-0.87.1-0.1.20060mdk.i586.rpm cffbc77a4bd7fec42d4807863d7b74f0 2006.0/RPMS/clamav-milter-0.87.1-0.1.20060mdk.i586.rpm 74bfb1f658a39d3989e14879467f3f22 2006.0/RPMS/clamd-0.87.1-0.1.20060mdk.i586.rpm 9ee1b202bc72d72d2ec743a96bb6cffa 2006.0/RPMS/libclamav1-0.87.1-0.1.20060mdk.i586.rpm 3c292c33d6386278dec59b4ea79a595b 2006.0/RPMS/libclamav1-devel-0.87.1-0.1.20060mdk.i586.rpm 6df60c1704c68f55c4340ef390031a45 2006.0/SRPMS/clamav-0.87.1-0.1.20060mdk.src.rpm Mandriva Linux 2006.0/X86_64: 180c192924ea9682c6b9038b374b6b03 x86_64/2006.0/RPMS/clamav-0.87.1-0.1.20060mdk.x86_64.rpm
[SECURITY] [DSA 889-1] New enigmail packages fix information disclosure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 889-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze November 8th, 2005 http://www.debian.org/security/faq - -- Package: enigmail Vulnerability : programming error Problem type : local (remote) Debian-specific: no CVE ID : CAN-2005-3256 CERT advisory : VU#805121 Debian Bug : 335731 A bug has been discovered in enigmail, GPG support for Mozilla MailNews and Mozilla Thunderbird, that can lead to the encryption of mail with the wrong public key, hence, potential disclosure of confidential data to others. The old stable distribution (woody) does not contain enigmail packages. For the stable distribution (sarge) this problem has been fixed in version 0.91-4sarge2. For the unstable distribution (sid) this problem has been fixed in version 0.93-1. We recommend that you upgrade your enigmail packages. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/e/enigmail/enigmail_0.91-4sarge2.dsc Size/MD5 checksum: 876 75a0758ff71b8651e26cb3d16320cb04 http://security.debian.org/pool/updates/main/e/enigmail/enigmail_0.91-4sarge2.diff.gz Size/MD5 checksum:17190 9d19e21a4feaf5177216646635949398 http://security.debian.org/pool/updates/main/e/enigmail/enigmail_0.91.orig.tar.gz Size/MD5 checksum: 2027147 b802d62ea602d82d8d0c69cc807bf83a Alpha architecture: http://security.debian.org/pool/updates/main/e/enigmail/mozilla-enigmail_0.91-4sarge2_alpha.deb Size/MD5 checksum: 345752 818ab632bcb4ea7e8b4105086aa2b904 http://security.debian.org/pool/updates/main/e/enigmail/mozilla-thunderbird-enigmail_0.91-4sarge2_alpha.deb Size/MD5 checksum: 350004 5087cf1624f2d70c5f0a543604556596 AMD64 architecture: http://security.debian.org/pool/updates/main/e/enigmail/mozilla-enigmail_0.91-4sarge2_amd64.deb Size/MD5 checksum: 314392 f9f5d14e6e0d000cfc3394ecdd6115d7 http://security.debian.org/pool/updates/main/e/enigmail/mozilla-thunderbird-enigmail_0.91-4sarge2_amd64.deb Size/MD5 checksum: 318672 d9fe5cf1c8c747e2c750f4687115f735 ARM architecture: http://security.debian.org/pool/updates/main/e/enigmail/mozilla-enigmail_0.91-4sarge2_arm.deb Size/MD5 checksum: 301182 0f7100552d152f8018726349de1bade3 http://security.debian.org/pool/updates/main/e/enigmail/mozilla-thunderbird-enigmail_0.91-4sarge2_arm.deb Size/MD5 checksum: 306332 cd5027429531a8c3b87d9a2c5e8b Intel IA-32 architecture: http://security.debian.org/pool/updates/main/e/enigmail/mozilla-enigmail_0.91-4sarge2_i386.deb Size/MD5 checksum: 298752 1ab5eee62ddb846a74441bc50d0120cf http://security.debian.org/pool/updates/main/e/enigmail/mozilla-thunderbird-enigmail_0.91-4sarge2_i386.deb Size/MD5 checksum: 304076 eb8586436db24bf342f69b1d3996c37e Intel IA-64 architecture: http://security.debian.org/pool/updates/main/e/enigmail/mozilla-enigmail_0.91-4sarge2_ia64.deb Size/MD5 checksum: 360432 cff589e212e6852048c65121be50e06c http://security.debian.org/pool/updates/main/e/enigmail/mozilla-thunderbird-enigmail_0.91-4sarge2_ia64.deb Size/MD5 checksum: 365434 f5571495756e2b8a72bf609bf2e73824 HP Precision architecture: http://security.debian.org/pool/updates/main/e/enigmail/mozilla-enigmail_0.91-4sarge2_hppa.deb Size/MD5 checksum: 321090 c2038c3d7274addf7387790275d668a1 http://security.debian.org/pool/updates/main/e/enigmail/mozilla-thunderbird-enigmail_0.91-4sarge2_hppa.deb Size/MD5 checksum: 325354 c285ed213fc3a9cc62bbe2c0ac84ca2e Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/e/enigmail/mozilla-enigmail_0.91-4sarge2_m68k.deb Size/MD5 checksum: 299930 6f45c5101ae36faa4bef8f4bfb5dedaa http://security.debian.org/pool/updates/main/e/enigmail/mozilla-thunderbird-enigmail_0.91-4sarge2_m68k.deb Size/MD5 checksum: 305212 aade8a0d36c5205034c845fa803c230f Big endian MIPS architecture: http://security.debian.org/pool/updates/main/e/enigmail/mozilla-enigmail_0.91-4sarge2_mips.deb Size/MD5 checksum: 308046 11eec39a832de3fe90794a5958044678
Re: Hidden accounts on sony vaio laptops
Not a Sony issue. This setup has been documented by MS since the release of Windows XP in 2001. Q: How can I add an Administrator password to make my computer more secure? A: Another way to make your computer more secure is to assign a password to the Administrator account, which is blank by default. An Administrator account is a user account that has full permissions and control over a computer, can gain access to and modify all user accounts on a computer, and can only be accessed from safe mode. http://www.microsoft.com/windowsxp/using/setup/getstarted/installqa.mspx Regards, Ken Williams ; Dir. Vuln Research Computer Associates ; 0xE2941985 List: bugtraq Subject:Hidden accounts on sony vaio laptops From: yash.kadakia () securityforge ! com Date: 2005-11-07 14:08:09 Sony Vaio laptops require you to create a user account the first time you start your laptop. If the user you select is not Administrator, Sony still goes ahead and creates a user Administrator with a blank password. This user does not show up in control panel under User Accounts but if you do start up in safemode the laptop allows you to login as Administrator. This gives an attacker an opportunity to gain administrative access to a computer and access to create add delete or modify user accounts. This is basically a backdoor account that is hidden from the user and compromises the security of all Sony Vaio laptops.
Advisory 21/2005: Multiple vulnerabilities in PHPKIT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hardened PHP Project
www.hardened-php.net
-= Security Advisory =-
Advisory: Multiple vulnerabilities in PHPKIT
Release Date: 2005/11/07
Last Modified: 2005/11/04
Author: Christopher Kunz [EMAIL PROTECTED]
Application: PHPKIT 1.6.1 R2 and prior
Severity: Cross-Site Scripting, SQL injection and information
disclosure, password hash disclosure, local file
disclosure, arbitrary code execution
Risk: High / Critical (depending on server configuration)
Vendor Status: No fix available
References: http://www.hardened-php.net/advisory_212005.80.html
Overview:
PHPKIT [1] is a combined content management, homepage building and community
software written in PHP. Although it is available as open source, it has
to be licensed for any other than private use. PHPKIT has the usual feat-
ures for that kind of product (content editing, forums, user management,
etc.). Typically for content management and portal systems, there are
multiple vulnerabilities in several places in the front- and backend.
The install base for PHPKIT can only be estimated - Google shows about
25,000 results for the query powered by phpkit [2].
Since we did not perform a full audit, there is no guarantee that the de-
scribed vulnerabilities are the only ones in the product.
Details:
1) XSS
Although the PHPKIT team seems to have made an effort to mitigate attacks
with cross-site scripting, this was only partially successful. We found
a number of critical XSS holes that can be exploited by any third party
to steal admin cookies, change HTML code, launch CSRF attacks and so on.
1.1) login/profile.php and login/userinfo.php
Two fields in the profile settings - those for AIM and Yahoo! screen
names - are inserted into the database without any input validation.
Thus, an XSS attack can be performed that is launched on any user who
looks at the offending profile.
The same attack can be launched on an administrator viewing a profile
via the administrator back-end.
1.2) admin/admin.php (with register_globals On)
Since the variable $site_body is not properly initialized, an attacker
can launch an XSS attack against the administrator login screen. This
attack can utilize DOM to steal the administrator's credentials in
cleartext as long as they have some kind of password safe function
in their browser. Since script code can be executed on load, all that
an attacker has to do is get the administrator to click on a manipula-
ted link.
1.3) Referrer statistics
By launching a HTTP request with the Referer set to some script code,
e.g. scriptalert('foo')/script, an attacker prompts this code to
be included in the administrative backend, and executed as soon as
an administrator views the referrer statistics. This comes in handy
since it is a quasi-anonymous way of obtaining the administrator's
session cookies.
1.4) Forum
Although input filtering takes place in the subject and content of
a forum postings, no such filtering is performed when constructing
the HTML title tag and the logo's img alt attribute - both con-
tain the thread subject in unfiltered HTML, and script code is execu-
ted twice per page.
1.5) imcenter.php
PHPKIT's own instant messaging system does not perform input validation
on the subject line, so any user can IM the admin and contain script
code in the subject.
1.6) Guestbook
The Homepage input field in the guest book is not properly sanitized
and any guest (no logged-in users, because their home page is not dis-
played by default) can enter script code. As usual, this is displayed
as soon as the guestbook is viewed.
2) SQL Injection
Same as above: Although many places inside the PHPKIT software are not
prone to SQL injection, some are. This leads to information disclosure
and possibly deletion of arbitrary data in the database.
2.1) SQL injection in profile pages (with magic_quotes_gpc Off)
Using a simple injection, any user of the PHPKIT-powered web site can
disclose the administrator's password hash. This is done via the $id
parameter in login/userinfo.php which is not properly sanitized. With
a crafted UNION statement, the attacker can obtain arbitrary data, in-
cluding but not limited to any user's password hash. A simple cast into
an int would have prevented this problem.
Example: include.php?path=login/userinfo.phpid='%20UNION%20SELECT%201,
1,user_pw,1,1,1,1,1,1,1,1,1,1,1,1,user_pw,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
