[Full-disclosure] FreeBSD crontab information leakage
FreeBSD crontab information leakage
For its implementation of the standard UNIX cron daemon, FreeBSD uses a version
based off vixie-cron. This package is installed by default, and includes a
setuid-root crontab binary to allow unprivileged users to list and modify their
own cronjobs.
I recently audited this code [1], and found a few interesting race conditions
and symlink attacks that allow for very minor information leakage. I thought
I'd share my findings because I enjoyed exploiting these issues and they don't
pose any significant risk to live systems - in other words, this advisory is
intended for system administrators and developers of FreeBSD-based systems;
journalists, end users and other non-technical readers do not need to be
concerned. :p
OpenBSD and NetBSD are not affected. Nor is Debian/Ubuntu cron, which is based
on vixie-cron 3.0, or Red Hat/Fedora cronie, which is a fork off ISC Cron (aka
vixie-cron 4.1). It seems the vulnerable code was specially inserted into the
FreeBSD codebase as additional security checks that introduced new issues of
their own. Perhaps it was inserted as a government-sponsored backdoor. Only
kidding. Because of its heavy reliance on FreeBSD source code, Mac OS X is
also affected [2], except for the realpath() case, which is conveniently
#ifdef'd out.
=
Leakage of file/directory existence via stat() calls
=
At two points (lines 366 and 436 in crontab.c), crontab makes calls to stat()
on a user-owned temporary file while retaining an euid of 0. Since stat()
follows symbolic links and returns ENOENT when called on a symbolic link
pointing to a non-existent resource, this can be used to determine the
existence of
files or directories in ways that violate directory search permissions.
The first of these instances, on line 436, is trivially exploitable. First,
invoke crontab with the -e flag to edit an existing cronjob. This will result
in crontab opening a text editor to edit the cronjob. While this editor is
open, simply remove the temporary file created by crontab (of the form
"/tmp/crontab.XX") and replace it with a symlink to a file whose
existence you wish to verify. On exiting the editor, crontab will print a
warning if the call to stat() on this symlink fails, confirming the
non-existence of the target file. Likewise, if the file exists, a different
error will be generated ("temp file must be edited in place").
The second of these instances, on line 366, doesn't have the luxury of an
editor holding everything up, and so requires exploitation of a race condition.
The temporary file is created on line 338. It can't be removed at this time,
since it's created with euid 0 in a presumably sticky-bit /tmp directory, but
shortly after it's fchown()'d to the user's id. At this point, if it's deleted
and replaced with a symlink to the file whose existence is to be confirmed, the
call to stat() on line 366 will perform identically to the first case.
==
Leakage of directory existence via realpath()
==
When crontab is run with a file argument, it makes a call to realpath() with
euid 0 to canonicalize the provided argument:
--snip--
} else if (realpath(Filename, resolved_path) != NULL &&
!strcmp(resolved_path, SYSCRONTAB)) {
err(ERROR_EXIT, SYSCRONTAB " must be edited manually");
}
--snip--
SYSCRONTAB is defined as /etc/crontab. Because realpath() resolves each member
of the requested path individually, in this case with euid 0, it's possible to
reveal the existence of directories regardless of search permissions, again
violating DAC. For example, consider the following request:
crontab /my/secret/directory/../../../../etc/crontab
If /my/secret/directory exists, realpath() will return a non-NULL value and the
resolved path will still be equal to SYSCRONTAB. If not, the above error
message will be displayed, because realpath() will return an error if any
directories in the search path do not exist.
MD5 comparisons for arbitrary files
FreeBSD's crontab calculates the MD5 sum of the previous and new cronjob to
determine if any changes have been made before copying the new version in.
This seems entirely superfluous to me, but maybe there's a good explanation.
In particular, it uses the MD5File() function, which takes a pathname as an
argument, and is again called with euid 0. The following relevant steps are
performed by crontab:
1. Create the temporary file (of the form "/tmp/crontab.XX")
2. chown() this file to the user's id
3. Open the existing cronjob and copy it into the temp file
4.
Re: [Full-disclosure] Python ssl handling could be better...
You're preaching to the choir...I agree there should be support, but don't go all talking about changing defaults without at least some thought involved. What about self-signed certs in my closed network? What about guests on a network behind a web proxy that MITMs 80/443? What if you're brokering a connection, not for some strict security sake, but just because you can and gain a little bit of privacy? Have any personal web sites/servers you don't *need* commercial certs for but want something anyway? In an ideal world, I hear what you're saying. But we're far from ideal... I think we should be happy with the inclusion of such options in 3.2 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Python ssl handling could be better...
+1 with a cherry on top! A cipher is a device for converting a plaintext distribution problem into a key distribution problem. An ephemeral key-agreement protocol (e.g., Diffie-Hellman) is a device for converting a key distribution problem into an authentication problem. Therefore, authentication is primary. One could say that unauthenticated encryption converts a passive eavesdropping attack into an active man-in-the-middle attack. On 02/27/2011 12:58 PM, bk wrote: > > - If you have the ability to sniff unencrypted traffic, you also have > the ability to hijack unauthenticated HTTPS traffic, it just that > simple. Of the population of people who login to a computer and try to protect information, the percentage of those who have ever used tcpdump or Wireshark is very small. Of those who have looked at a packet capture, the percentage who have ever experimented with active network attack tools is even smaller. Nevertheless, there are off-the-shelf systems that will do it at production scale. Most of us find it much easier to obtain and view a pcap than set up an active man-in-the-middle attack scenario. So converting the attacker from a passive eavesdropper to an active on-line attacker (who probably had to plan ahead a little bit) sure seems like it would represent an increase in security. And maybe it is if you're only defending against the random internet malware of today. But it's of little use if you need to be concerned about a targeted attack (i.e., you have, know, or are something worth defending). Just ask the Iranian government or the Tunisian people. > - ENCRYPTION IS POINTLESS WITHOUT AUTHENTICATION Maybe it's even worse than pointless. 1. Insufficiently-authenticated encryption inevitably gives a false sense of security. 2. Encryption can cause open vulnerabilities to be hidden to passive network monitoring systems. 3. But attackers are not constrained to be passive. Encryption can cause active, ongoing attacks to be hidden from monitoring. Humans, like all living things, have over millions of years evolved sophisticated built-in mechanisms for recognizing each other. We have so much authentication going on at an automatic level that we find it very difficult to judge the magnitude of the task. This is exactly the type of situation that favors the hackers, pentesters, and dictators of countries where the ISPs operate under the Ministry of Information. Let's not make it so easy that it takes all the fun out of it for them. - Marsh ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] BackWPup Wordpress plugin <= 1.4.0 File content disclosure
=
- Release date: Feb 28th, 2010
- Discovered by: Danilo Massa
- Severity: High
=
I. VULNERABILITY
-
BackWPup Wordpress plugin <= 1.4.0 File content disclosure
II. BACKGROUND
-
BackWPup 1.4.0 is a full-featured backup management solution for Wordpress.
The plugin provide:
- Database Backup
- WordPress XML Export
- Optimize Database
- Check\Repair Database
- File Backup
- Backups in zip,tar,tar.gz,tar.bz2 format
- Store backup to Folder
- Store backup to FTP Server
- Store backup to Amazon S3
- Store backup to RackSpaceCloud
- Store backup to DropBox
- Send Log/Backup by eMail
III. INTRODUCTION
-
BackWPup version 1.4.0 (and may be the previous ones too) has an unfiltered
parameter inside
two php pages that let a remote user to access sensitive files like /etc/passwd.
No authentication required. No plugin activation required.
IV. DESCRIPTION
-
Input passed via the "wpabs" parameter to the php pages
- wp-content/plugins/backwpup/app/options-view_log-iframe.php
- wp-content/plugins/backwpup/app/options-runnow-iframe.php
is not sanitized before being used.
Both files starts trying to include the wp-load.php file using the wpabs
parameter that can
be inject with a direct call to the page.
options-view_log-iframe.php:
/wp-content/plugins/backwpup/app/options-runnow-iframe.php?wpabs=/etc/passwd%00&jobid=1
http:///wp-content/plugins/backwpup/app/options-view_log-iframe.php?wpabs=/etc/passwd%00&logfile=/etc/passwd
Both of them will display the /etc/passwd file.
VI. BUSINESS IMPACT
-
An attacker could exploit the vulnerability to retrieve virtually any text file
accessible by the wep application server user.
VII. SYSTEMS AFFECTED
-
Version 1.4.0 is vulnerable.
Versions <1.4.0 could be vulnerable.
VIII. SOLUTION
-
Upgrade to a patched release or as quick workaround enclose
any $_GET['wpabs'] in a trim call like this:
if (file_exists(trim($_GET['wpabs']).'wp-load.php') and
file_exists($_GET['logfile'])) {
IX. REFERENCES
-
http://wordpress.org/extend/plugins/backwpup/
http://danielhuesken.de/portfolio/backwpup/
X. CREDITS
-
The vulnerability has been discovered by Danilo Massa
danilo(under_score)m(at)yahoo(dot)com
XI. VULNERABILITY HISTORY
-
January 28th, 2011: Vulnerability identification
January 30th, 2011: Vendor notification
January 30th, 2011: Vendor release an updated version (1.4.1)
February 28th, 2011: Vulnerability disclosure
XII. LEGAL NOTICES
-
The information contained within this advisory is supplied "as-is" with
no warranties or guarantees of fitness of use or otherwise. I accept no
responsibility for any damage caused by the use or misuse of this
information.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ MDVSA-2011:038 ] samba
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2011:038 http://www.mandriva.com/security/ ___ Package : samba Date: February 28, 2011 Affected: 2009.0, 2010.0, 2010.1, Corporate 4.0, Enterprise Server 5.0 ___ Problem Description: A vulnerability has been found and corrected in samba: All current released versions of Samba are vulnerable to a denial of service caused by memory corruption. Range checks on file descriptors being used in the FD_SET macro were not present allowing stack corruption. This can cause the Samba code to crash or to loop attempting to select on a bad file descriptor set (CVE-2011-0719). Packages for 2009.0 are provided as of the Extended Maintenance Program. Please visit this link to learn more: http://store.mandriva.com/product_info.php?cPath=149&products_id=490 The updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0719 ___ Updated Packages: Mandriva Linux 2009.0: 47c066ad29565628aaed4e0f6aeb2901 2009.0/i586/libnetapi0-3.3.12-0.5mdv2009.0.i586.rpm 46c96353d0122188f336e3a47c9ddc9f 2009.0/i586/libnetapi-devel-3.3.12-0.5mdv2009.0.i586.rpm 61ca8a12ee568461840e86bde470c7c0 2009.0/i586/libsmbclient0-3.3.12-0.5mdv2009.0.i586.rpm f5188e114eb88ecd5658fab1d6f454b5 2009.0/i586/libsmbclient0-devel-3.3.12-0.5mdv2009.0.i586.rpm dc653696da846718bdeaf61e2a9a89f9 2009.0/i586/libsmbclient0-static-devel-3.3.12-0.5mdv2009.0.i586.rpm 3c6fc2ffa9617b276a2dac5d3846eb4d 2009.0/i586/libsmbsharemodes0-3.3.12-0.5mdv2009.0.i586.rpm 0822e35cc7eeed5a5b95c02daebe175b 2009.0/i586/libsmbsharemodes-devel-3.3.12-0.5mdv2009.0.i586.rpm 6264a83254c76b87d7099d4988d6dac3 2009.0/i586/libtalloc1-3.3.12-0.5mdv2009.0.i586.rpm e59b12c295dd797a0bb9b6b89d1d7cdb 2009.0/i586/libtalloc-devel-3.3.12-0.5mdv2009.0.i586.rpm 7a6e51482d44c417f1861e938b78cafd 2009.0/i586/libtdb1-3.3.12-0.5mdv2009.0.i586.rpm b093d84d95edaaf035557439d092f187 2009.0/i586/libtdb-devel-3.3.12-0.5mdv2009.0.i586.rpm 13a8be1be9019767d9a0e13e0482e498 2009.0/i586/libwbclient0-3.3.12-0.5mdv2009.0.i586.rpm 54e4c8e1b0d5c4964ca7f0c25809a8f5 2009.0/i586/libwbclient-devel-3.3.12-0.5mdv2009.0.i586.rpm 5f48b8beb4ef89d0bb46c1c7c0c9d548 2009.0/i586/mount-cifs-3.3.12-0.5mdv2009.0.i586.rpm f989757c51950aa4d75d0f34f5d95d2a 2009.0/i586/nss_wins-3.3.12-0.5mdv2009.0.i586.rpm 9e409b6485890e7de6c4fdc0184fbdbd 2009.0/i586/samba-client-3.3.12-0.5mdv2009.0.i586.rpm 6fa583bad8597d1ae779109fe02a95ae 2009.0/i586/samba-common-3.3.12-0.5mdv2009.0.i586.rpm 373566cfe0634a45d23562eafe6f1b39 2009.0/i586/samba-doc-3.3.12-0.5mdv2009.0.i586.rpm 362737879872a4ff3da264c9e4efdc16 2009.0/i586/samba-server-3.3.12-0.5mdv2009.0.i586.rpm 00c6b67c768b55c9b4d48b11d0485e01 2009.0/i586/samba-swat-3.3.12-0.5mdv2009.0.i586.rpm 1205afa765306f3e5a436c7528e9082d 2009.0/i586/samba-winbind-3.3.12-0.5mdv2009.0.i586.rpm a7a117b9c4f9cf6ddf902f5b233d353e 2009.0/SRPMS/samba-3.3.12-0.5mdv2009.0.src.rpm Mandriva Linux 2009.0/X86_64: 591db6c4c602f6124bd13d3d9e82efc7 2009.0/x86_64/lib64netapi0-3.3.12-0.5mdv2009.0.x86_64.rpm 4267a9aee4bd443b5bddbb3eaeb683a7 2009.0/x86_64/lib64netapi-devel-3.3.12-0.5mdv2009.0.x86_64.rpm c2691ab6b82c57e74aad43e2c2deeae5 2009.0/x86_64/lib64smbclient0-3.3.12-0.5mdv2009.0.x86_64.rpm 4a2ce9fdb981a23f1a8b69a14ed42882 2009.0/x86_64/lib64smbclient0-devel-3.3.12-0.5mdv2009.0.x86_64.rpm 47351f0feb53085fb6a1769b7397cedc 2009.0/x86_64/lib64smbclient0-static-devel-3.3.12-0.5mdv2009.0.x86_64.rpm 0b984c5c678f6243af714c8b4ed3767b 2009.0/x86_64/lib64smbsharemodes0-3.3.12-0.5mdv2009.0.x86_64.rpm 13504eae71feb8e679ce87f1152c21c2 2009.0/x86_64/lib64smbsharemodes-devel-3.3.12-0.5mdv2009.0.x86_64.rpm ce5ef2fdf418e039476c0eea1b152c1e 2009.0/x86_64/lib64talloc1-3.3.12-0.5mdv2009.0.x86_64.rpm 59b1b49773060dca1ee5f2e5a8d287dd 2009.0/x86_64/lib64talloc-devel-3.3.12-0.5mdv2009.0.x86_64.rpm b0f52be8b0321775e3ea1bbee9724201 2009.0/x86_64/lib64tdb1-3.3.12-0.5mdv2009.0.x86_64.rpm a8217963821af3562cf9187e038f8aef 2009.0/x86_64/lib64tdb-devel-3.3.12-0.5mdv2009.0.x86_64.rpm 86598cfcc7cdf5bff259cdff2512a1a6 2009.0/x86_64/lib64wbclient0-3.3.12-0.5mdv2009.0.x86_64.rpm 028f1e5e1ea02c0d3f01105fed0ac676 2009.0/x86_64/lib64wbclient-devel-3.3.12-0.5mdv2009.0.x86_64.rpm 4920bdf824db839beb87621c9d4a4191 2009.0/x86_64/mount-cifs-3.3.12-0.5mdv2009.0.x86_64.rpm 94d4478482bfc9030d1a163904090dad 2009.0/x86_64/nss_wins-3.3.12-0.5mdv2009.0.x86_64.rpm 841c26fe2ea2e193dec2bc8b9670c6ce 2009.0/x86_64/samba-client-3.3
Re: [Full-disclosure] Python ssl handling could be better...
Sigh, sending with correct account... On Feb 28, 2011, at 9:34 AM, Michael Krymson wrote: > > What about self-signed certs in my closed network? The ssl.py module (library/whatever) has support for selectively disabling certificate verification. This parameter should be exposed up the stack in modules that rely on it. The second major problem here is that httplib.py does not support that parameter, so anything higher in the stack is tied to the (incorrect) default. That's the thing with default behaviors: The default should be set to something sane (in the case of encryption, SECURE) and there should be a way to override it if a significant number of users will want to do so (two strikes against the Python dev team). BTW there really isn't a security difference between encrypted-but-unauthenticated traffic and just plain unencrypted traffic. The only "attacker" you're defeating is a casual observer, who probably is more curious than harmful. Determined attackers who are out to harm you are going to get the information any way. If something is important enough to encrypt traffic to/from, it's important enough to authenticate too, otherwise it isn't worth the hassle at all. > What about guests on a network behind a web proxy that MITMs 80/443? If you're intentionally MITM client traffic, the client should trust your MITM CA. If you aren't doing it that way, ur doin it rong. You basically just compromised the security of all of your end-points and are training your users to ignore warnings. In the case of Python apps, you're teaching your developers insecure coding practices. It's cascading stupidity. > What if you're brokering a connection, not for some strict security sake, but > just because you can and gain a little bit of privacy? Have any personal web > sites/servers you don't *need* commercial certs for but want something anyway? See above. > > In an ideal world, I hear what you're saying. But we're far from ideal... It's not ideal because people take the lazy way and assume that unauthenticated encryption is "good enough." It's not good enough because it's trivially broken. It used to be (say, a decade ago) less risky because there weren't readily available tools everywhere that could do the active MITM, but now there are and everyone has already learned to be lazy, so we're at a net deficit from the starting point. Every time you tell yourself "it could be broken, but I'm sure no one will make that much of an effort" you're wrong and just made a fundamental mistaken. > > I think we should be happy with the inclusion of such options in 3.2 No, I'm not going to be happy about an after-thought fix. At least httplib.py should never have been put in the tree without an option to tell ssl.py to verify the server cert. FFS they have client cert support, would it REALLY be that hard to pass the verification parameter to ssl.py? No, it's just sheer ignorance of security. -- chort ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [USN-1075-1] Samba vulnerability
=== Ubuntu Security Notice USN-1075-1 February 28, 2011 samba vulnerability CVE-2011-0719 === A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 8.04 LTS Ubuntu 9.10 Ubuntu 10.04 LTS Ubuntu 10.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: samba 3.0.22-1ubuntu3.14 Ubuntu 8.04 LTS: samba 3.0.28a-1ubuntu4.14 Ubuntu 9.10: samba 2:3.4.0-3ubuntu5.8 Ubuntu 10.04 LTS: samba 2:3.4.7~dfsg-1ubuntu3.4 Ubuntu 10.10: samba 2:3.5.4~dfsg-1ubuntu8.3 In general, a standard system update will make all the necessary changes. Details follow: Volker Lendecke discovered that Samba incorrectly handled certain file descriptors. A remote attacker could send a specially crafted request to the server and cause Samba to crash or hang, resulting in a denial of service. Updated packages for Ubuntu 6.06 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba_3.0.22-1ubuntu3.14.diff.gz Size/MD5: 169665 0ece5aa29a3f84eebda13c6d64b49248 http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba_3.0.22-1ubuntu3.14.dsc Size/MD5: 1846 14e3c068c7690f01b8cbb32e50e6c11f http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba_3.0.22.orig.tar.gz Size/MD5: 17542657 5c39505af17cf5caf3d6ed8bab135036 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba-doc-pdf_3.0.22-1ubuntu3.14_all.deb Size/MD5: 6595258 4854e8c5b4b02c1627767d6402cb47eb http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba-doc_3.0.22-1ubuntu3.14_all.deb Size/MD5: 6903064 f0920a669f3ae85129e1284f3455fc98 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/s/samba/libpam-smbpass_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 428066 ef5430d2ecf0b541cedf02556773a72a http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient-dev_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 113450 2c7676f2f0a09feb1d970ae612292a31 http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 799492 5d6b50da50a7252071113d376cc90357 http://security.ubuntu.com/ubuntu/pool/main/s/samba/python2.4-samba_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 596 15b26e9253e7a8949ecfd779a7f2b943 http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba-common_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 2417834 e27bf6e3ada11f5febb33b25467985bc http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba-dbg_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 11897966 b834a6d7b0459dfe72405819c7b7a7f1 http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 3407048 6e1c4e963306143a1e220b1196f1d7e5 http://security.ubuntu.com/ubuntu/pool/main/s/samba/smbclient_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 4045438 26426178e0b6bd4ddc3102ebde1a5b5d http://security.ubuntu.com/ubuntu/pool/main/s/samba/smbfs_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 451274 d9b12f8c98906112e44073e6bd4942e3 http://security.ubuntu.com/ubuntu/pool/main/s/samba/swat_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 834814 c9678655fd655168ad4ed2a225edef8b http://security.ubuntu.com/ubuntu/pool/main/s/samba/winbind_3.0.22-1ubuntu3.14_amd64.deb Size/MD5: 1933506 2382ce9dc5f5e6f41206360447c98706 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/s/samba/libpam-smbpass_3.0.22-1ubuntu3.14_i386.deb Size/MD5: 367400 63912bec34786f7ad73d732cc86c7618 http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient-dev_3.0.22-1ubuntu3.14_i386.deb Size/MD5: 113448 09680c55bdf9ffc92c71df0f977b64a5 http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient_3.0.22-1ubuntu3.14_i386.deb Size/MD5: 684500 1401f7a750f8e6cf5b02c1bfa4a3a6b1 http://security.ubuntu.com/ubuntu/pool/main/s/samba/python2.4-samba_3.0.22-1ubuntu3.14_i386.deb Size/MD5: 5072252 2346916a59e224427e567e00776b5f6b http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba-common_3.0.22-1ubuntu3.14_i386.deb Size/MD5: 2080498 5bdf52b93d2440cc81c759511262e677 http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba-dbg_3.0.22-1ubuntu3.14_i386.deb Size/MD5: 9813412 751a91f5ea84825873c2274751f572de http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba_3.0.22-1ubuntu3.14_i386.deb Size/MD5: 2855458 165c22542e8be77b16adb10a771e9156 http://security.ubuntu.com/ubuntu/pool/main/s/samb
[Full-disclosure] [USN-1076-1] ClamAV vulnerability
=== Ubuntu Security Notice USN-1076-1 February 28, 2011 clamav vulnerability CVE-2011-1003 === A security issue affects the following Ubuntu releases: Ubuntu 9.10 Ubuntu 10.04 LTS Ubuntu 10.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 9.10: libclamav6 0.95.3+dfsg-1ubuntu0.09.10.4 Ubuntu 10.04 LTS: libclamav6 0.96.5+dfsg-1ubuntu1.10.04.2 Ubuntu 10.10: libclamav6 0.96.5+dfsg-1ubuntu1.10.10.2 In general, a standard system update will make all the necessary changes. Details follow: It was discovered that the Microsoft Office processing code in libclamav improperly handled certain Visual Basic for Applications (VBA) data. This could allow a remote attacker to craft a document that could crash clamav or possibly execute arbitrary code. In the default installation, attackers would be isolated by the ClamAV AppArmor profile. Updated packages for Ubuntu 9.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav_0.95.3+dfsg-1ubuntu0.09.10.4.diff.gz Size/MD5: 266751 b92bfa373bb70a45a6a6b9da28ed6f3f http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav_0.95.3+dfsg-1ubuntu0.09.10.4.dsc Size/MD5: 2200 11176ce261f337f98615e64abf25069d http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav_0.95.3+dfsg.orig.tar.gz Size/MD5: 26892533 dfe1348c52223ab48f049123021aea4a Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav-base_0.95.3+dfsg-1ubuntu0.09.10.4_all.deb Size/MD5: 24052698 07823a204b0184c393d21eb73756ee61 http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav-docs_0.95.3+dfsg-1ubuntu0.09.10.4_all.deb Size/MD5: 1130156 4a71ebc89c1fd2f12212e056667b87f5 http://security.ubuntu.com/ubuntu/pool/universe/c/clamav/clamav-testfiles_0.95.3+dfsg-1ubuntu0.09.10.4_all.deb Size/MD5: 232322 6f1249909788dde6b529d50a3d63df7d amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav-daemon_0.95.3+dfsg-1ubuntu0.09.10.4_amd64.deb Size/MD5: 383424 297b54ad42f073d0d8d4d05b12976d49 http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav-dbg_0.95.3+dfsg-1ubuntu0.09.10.4_amd64.deb Size/MD5: 1101424 82e2344ab87ff2c236ebb49e29c27794 http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav-freshclam_0.95.3+dfsg-1ubuntu0.09.10.4_amd64.deb Size/MD5: 288914 881eb37183a88d1da7e72fc35694038b http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav_0.95.3+dfsg-1ubuntu0.09.10.4_amd64.deb Size/MD5: 281396 17da940e0a1f4ba23d449a7f8e2e5965 http://security.ubuntu.com/ubuntu/pool/main/c/clamav/libclamav-dev_0.95.3+dfsg-1ubuntu0.09.10.4_amd64.deb Size/MD5: 623244 3ef5257416648e31a31237833bb85637 http://security.ubuntu.com/ubuntu/pool/main/c/clamav/libclamav6_0.95.3+dfsg-1ubuntu0.09.10.4_amd64.deb Size/MD5: 584348 b6575b4d17950ffd6265d4da98a0b449 http://security.ubuntu.com/ubuntu/pool/universe/c/clamav/clamav-milter_0.95.3+dfsg-1ubuntu0.09.10.4_amd64.deb Size/MD5: 309392 b2770bd551c6c4de5aafaf2def4234a2 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav-daemon_0.95.3+dfsg-1ubuntu0.09.10.4_i386.deb Size/MD5: 370028 d3fb2fe77201b9a6eb350b0526c2d746 http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav-dbg_0.95.3+dfsg-1ubuntu0.09.10.4_i386.deb Size/MD5: 1059028 02d70b012003fc08d78b00fa8ad0f088 http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav-freshclam_0.95.3+dfsg-1ubuntu0.09.10.4_i386.deb Size/MD5: 284590 d419566e6897a6e6e0e9c108295043b4 http://security.ubuntu.com/ubuntu/pool/main/c/clamav/clamav_0.95.3+dfsg-1ubuntu0.09.10.4_i386.deb Size/MD5: 275360 b0136ae6dc82a6c378659fdead534504 http://security.ubuntu.com/ubuntu/pool/main/c/clamav/libclamav-dev_0.95.3+dfsg-1ubuntu0.09.10.4_i386.deb Size/MD5: 585258 dbdb318fb8f6a0330cf2e0c57c087b3e http://security.ubuntu.com/ubuntu/pool/main/c/clamav/libclamav6_0.95.3+dfsg-1ubuntu0.09.10.4_i386.deb Size/MD5: 567976 4bd9888413fae10c335b72543aaf641b http://security.ubuntu.com/ubuntu/pool/universe/c/clamav/clamav-milter_0.95.3+dfsg-1ubuntu0.09.10.4_i386.deb Size/MD5: 303144 78c86ec166f8072319eb40ec5e3ca1db armel architecture (ARM Architecture): http://ports.ubuntu.com/pool/main/c/clamav/clamav-daemon_0.95.3+dfsg-1ubuntu0.09.10.4_armel.deb Size/MD5: 372168 a30ec034c21cb0a3403937307c381492 http://ports.ubuntu.com/pool/main/c/clamav/clamav-dbg_0.95.3+dfsg-1ubuntu0.09.10.4_armel.deb Si
[Full-disclosure] [USN-1077-1] FUSE vulnerabilities
=== Ubuntu Security Notice USN-1077-1 February 28, 2011 fuse vulnerabilities CVE-2009-3297, CVE-2011-0541, CVE-2011-0542, CVE-2011-0543 === A security issue affects the following Ubuntu releases: Ubuntu 8.04 LTS Ubuntu 9.10 Ubuntu 10.04 LTS Ubuntu 10.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 8.04 LTS: fuse-utils 2.7.2-1ubuntu2.3 Ubuntu 9.10: fuse-utils 2.7.4-1.1ubuntu4.5 Ubuntu 10.04 LTS: fuse-utils 2.8.1-1.1ubuntu3.1 Ubuntu 10.10: fuse-utils 2.8.4-1ubuntu1.3 In general, a standard system update will make all the necessary changes. Details follow: It was discovered that FUSE would incorrectly follow symlinks when checking mountpoints under certain conditions. A local attacker, with access to use FUSE, could unmount arbitrary locations, leading to a denial of service. Updated packages for Ubuntu 8.04 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/f/fuse/fuse_2.7.2-1ubuntu2.3.diff.gz Size/MD5:24330 d6ef479dae54fbe76fa652c172239905 http://security.ubuntu.com/ubuntu/pool/main/f/fuse/fuse_2.7.2-1ubuntu2.3.dsc Size/MD5: 1551 a078e7da97c67a2e8932974152daa1d2 http://security.ubuntu.com/ubuntu/pool/main/f/fuse/fuse_2.7.2.orig.tar.gz Size/MD5: 505855 813782a4f23211386c1ea91dc0ac7ded Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/universe/f/fuse/fuse-source_2.7.2-1ubuntu2.3_all.deb Size/MD5: 191676 b3f6c0093d178ce8e76f6592803ec8a7 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/f/fuse/fuse-utils-udeb_2.7.2-1ubuntu2.3_amd64.udeb Size/MD5:19762 3dbb99bb10afa5e8580639d41309ca3d http://security.ubuntu.com/ubuntu/pool/main/f/fuse/fuse-utils_2.7.2-1ubuntu2.3_amd64.deb Size/MD5:23064 ed4e1f161d2018dbce11fad969ce4b39 http://security.ubuntu.com/ubuntu/pool/main/f/fuse/libfuse-dev_2.7.2-1ubuntu2.3_amd64.deb Size/MD5: 167036 1bd5f2ffdeb23a251939d6600fabe96e http://security.ubuntu.com/ubuntu/pool/main/f/fuse/libfuse2-udeb_2.7.2-1ubuntu2.3_amd64.udeb Size/MD5:55546 6ddebf5875a60a59182109ec0630f913 http://security.ubuntu.com/ubuntu/pool/main/f/fuse/libfuse2_2.7.2-1ubuntu2.3_amd64.deb Size/MD5: 131644 90a5e215cdc19c862fcfa075d9f0e541 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/f/fuse/fuse-utils-udeb_2.7.2-1ubuntu2.3_i386.udeb Size/MD5:17826 66d83ca40fb67c83e05d1a44a8622426 http://security.ubuntu.com/ubuntu/pool/main/f/fuse/fuse-utils_2.7.2-1ubuntu2.3_i386.deb Size/MD5:21102 9297e1368899103d96d48392b4b4dc8c http://security.ubuntu.com/ubuntu/pool/main/f/fuse/libfuse-dev_2.7.2-1ubuntu2.3_i386.deb Size/MD5: 155542 b17c48ef18df2d52c7d91623c2e707c9 http://security.ubuntu.com/ubuntu/pool/main/f/fuse/libfuse2-udeb_2.7.2-1ubuntu2.3_i386.udeb Size/MD5:49892 5e8748580b4d8ec1c37ee97d00b101e0 http://security.ubuntu.com/ubuntu/pool/main/f/fuse/libfuse2_2.7.2-1ubuntu2.3_i386.deb Size/MD5: 125352 25ed0a8c070abc4b9345b1bf254c6db9 lpia architecture (Low Power Intel Architecture): http://ports.ubuntu.com/pool/main/f/fuse/fuse-utils-udeb_2.7.2-1ubuntu2.3_lpia.udeb Size/MD5:17862 d147f034c63b04aaeffd083ff30e5445 http://ports.ubuntu.com/pool/main/f/fuse/fuse-utils_2.7.2-1ubuntu2.3_lpia.deb Size/MD5:21138 bcc85dc0d9aa1973ead2c86f73be5a2a http://ports.ubuntu.com/pool/main/f/fuse/libfuse-dev_2.7.2-1ubuntu2.3_lpia.deb Size/MD5: 155216 4ad62bef3195f4a87a418514fd0d644e http://ports.ubuntu.com/pool/main/f/fuse/libfuse2-udeb_2.7.2-1ubuntu2.3_lpia.udeb Size/MD5:48880 23b7a60d3980bace5fb73e3a8cbfe0fb http://ports.ubuntu.com/pool/main/f/fuse/libfuse2_2.7.2-1ubuntu2.3_lpia.deb Size/MD5: 124416 88d4c437a14924d9f216af6f80c7e0cc powerpc architecture (Apple Macintosh G3/G4/G5): http://ports.ubuntu.com/pool/main/f/fuse/fuse-utils-udeb_2.7.2-1ubuntu2.3_powerpc.udeb Size/MD5:20450 e8129436745cdb1ea94003ed147fb1df http://ports.ubuntu.com/pool/main/f/fuse/fuse-utils_2.7.2-1ubuntu2.3_powerpc.deb Size/MD5:23738 c46e9a8f48acabfbbd91cbeb3c50da22 http://ports.ubuntu.com/pool/main/f/fuse/libfuse-dev_2.7.2-1ubuntu2.3_powerpc.deb Size/MD5: 164144 7d444b274b9804b7a4e15071a10c69ae http://ports.ubuntu.com/pool/main/f/fuse/libfuse2-udeb_2.7.2-1ubuntu2.3_powerpc.udeb Size/MD5:56026 6755a969f53d79606407ebf7d2103010 http://ports.ubuntu.com/pool/main/f/fuse/libfuse2_2.7.2-1ubuntu2.3_powerpc.deb Size/MD5: 131934 2127225883583b481e7b
[Full-disclosure] Vulnerabilities in phpMyAdmin
Hello list! I want to warn you about Brute Force and Full path disclosure vulnerabilities in phpMyAdmin. CVE id: CVE-2011-0986. WASC ids: WASC-11, WASC-13. CWE ids: CWE-661, CWE-200. - Affected products: - Vulnerable are phpMyAdmin 3.3.9 and previous versions and phpMyAdmin 2.11.11.1 and previous versions. All applications (such as XAMPP), which are using phpMyAdmin, are also vulnerable. Full path disclosure vulnerabilities were fixed by developers in versions 3.3.9.1 and 2.11.11.2. -- Details: -- Brute Force (WASC-11): http://site/phpmyadmin/ In login form there is no protection from Brute Force attacks. Full path disclosure (WASC-13): http://site/phpmyadmin/readme.php (if there is no README file in folder phpmyadmin) http://site/phpmyadmin/changelog.php (if there is no ChangeLog file in folder phpmyadmin) http://site/phpmyadmin/license.php (if there is no LICENSE file in folder phpmyadmin) Timeline: 2011.01.25 - announced at my site. 2011.01.26 - informed developers. 2011.01.31 - received answer from developers. 2011-02-01 - I gave developers additional argumentations and recommendations about fixing Brute Force and Full path disclosure holes and privately informed about all those Fingerprinting (WASC-45) holes in phpMyAdmin. 2011-02-08 - developers fixed FPD holes (http://www.phpmyadmin.net/home_page/security/PMASA-2011-1.php). 2011.02.28 - disclosed at my site. I mentioned about these vulnerabilities at my site (http://websecurity.com.ua/4872/). Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [USN-1074-2] Linux kernel vulnerabilities
=== Ubuntu Security Notice USN-1074-2 February 28, 2011 linux-fsl-imx51 vulnerabilities CVE-2009-4895, CVE-2010-2066, CVE-2010-2226, CVE-2010-2248, CVE-2010-2478, CVE-2010-2495, CVE-2010-2521, CVE-2010-2524, CVE-2010-2538, CVE-2010-2798, CVE-2010-2942, CVE-2010-2943, CVE-2010-2946, CVE-2010-2954, CVE-2010-2955, CVE-2010-2962, CVE-2010-2963, CVE-2010-3015, CVE-2010-3067, CVE-2010-3078, CVE-2010-3079, CVE-2010-3080, CVE-2010-3081, CVE-2010-3084, CVE-2010-3296, CVE-2010-3297, CVE-2010-3298, CVE-2010-3301, CVE-2010-3310, CVE-2010-3432, CVE-2010-3437, CVE-2010-3442, CVE-2010-3448, CVE-2010-3477, CVE-2010-3698, CVE-2010-3705, CVE-2010-3848, CVE-2010-3849, CVE-2010-3850, CVE-2010-3858, CVE-2010-3861, CVE-2010-3904, CVE-2010-4072, CVE-2010-4073, CVE-2010-4074, CVE-2010-4078, CVE-2010-4079, CVE-2010-4165, CVE-2010-4169, CVE-2010-4249 === A security issue affects the following Ubuntu releases: Ubuntu 10.04 LTS This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 10.04 LTS: linux-image-2.6.31-608-imx512.6.31-608.22 After a standard system update you need to reboot your computer to make all the necessary changes. Details follow: USN-1074-1 fixed vulnerabilities in linux-fsl-imx51 in Ubuntu 9.10. This update provides the corresponding updates for Ubuntu 10.04. Original advisory details: Al Viro discovered a race condition in the TTY driver. A local attacker could exploit this to crash the system, leading to a denial of service. (CVE-2009-4895) Dan Rosenberg discovered that the MOVE_EXT ext4 ioctl did not correctly check file permissions. A local attacker could overwrite append-only files, leading to potential data loss. (CVE-2010-2066) Dan Rosenberg discovered that the swapexit xfs ioctl did not correctly check file permissions. A local attacker could exploit this to read from write-only files, leading to a loss of privacy. (CVE-2010-2226) Gael Delalleu, Rafal Wojtczuk, and Brad Spengler discovered that the memory manager did not properly handle when applications grow stacks into adjacent memory regions. A local attacker could exploit this to gain control of certain applications, potentially leading to privilege escalation, as demonstrated in attacks against the X server. (CVE-2010-2240) Suresh Jayaraman discovered that CIFS did not correctly validate certain response packats. A remote attacker could send specially crafted traffic that would crash the system, leading to a denial of service. (CVE-2010-2248) Ben Hutchings discovered that the ethtool interface did not correctly check certain sizes. A local attacker could perform malicious ioctl calls that could crash the system, leading to a denial of service. (CVE-2010-2478, CVE-2010-3084) James Chapman discovered that L2TP did not correctly evaluate checksum capabilities. If an attacker could make malicious routing changes, they could crash the system, leading to a denial of service. (CVE-2010-2495) Neil Brown discovered that NFSv4 did not correctly check certain write requests. A remote attacker could send specially crafted traffic that could crash the system or possibly gain root privileges. (CVE-2010-2521) David Howells discovered that DNS resolution in CIFS could be spoofed. A local attacker could exploit this to control DNS replies, leading to a loss of privacy and possible privilege escalation. (CVE-2010-2524) Dan Rosenberg discovered that the btrfs filesystem did not correctly validate permissions when using the clone function. A local attacker could overwrite the contents of file handles that were opened for append-only, or potentially read arbitrary contents, leading to a loss of privacy. Only Ubuntu 9.10 was affected. (CVE-2010-2538) Bob Peterson discovered that GFS2 rename operations did not correctly validate certain sizes. A local attacker could exploit this to crash the system, leading to a denial of service. (CVE-2010-2798) Kees Cook discovered that under certain situations the ioctl subsystem for DRM did not properly sanitize its arguments. A local attacker could exploit this to read previously freed kernel memory, leading to a loss of privacy. (CVE-2010-2803) Eric Dumazet discovered that many network functions could leak kernel stack contents. A local attacker could exploit this to read portions of kernel memory, leading to a loss of privacy. (CVE-2010-2942, CVE-2010-3477) Dave Chinner discovered that the XFS filesystem did not correctly order inode lookups when exported by NFS. A remote attacker could exploit this to read or write disk blocks that had changed file assignment or had become unlinked, leading to a loss of privacy. (CVE-2010-2943) Sergey Vlasov discovered that JFS did not correctly handle certain
[Full-disclosure] weechat does not properly use gnutls and allow an attacker to bypass certificate verification
About WeeChat: "WeeChat is a fast, light and extensible chat client. It runs on many platforms (including Linux, BSD and Mac OS). Development is very active, and bug fixes are very fast!" The vuln: Weechat does not use the GnuTLS API properly to check certificates, potentially exposing users to man-in-the-middle attacks. Weechat registers a callback function to be called by GnuTLS during the TLS/SSL handshake. The function perform checks on the server certificate and optionally, send a client certificate. The mentioned code is located in src/core/wee-network.c in the network_init function: gnutls_certificate_client_set_retrieve_function (gnutls_xcred, &hook_connect_gnutls_set_certificates); Excerpt from gnutls's doc: gnutls_certificate_client_set_retrieve_function sets a callback to be called in order to retrieve the certificate to be used in the handshake. (...) If the callback function is provided then gnutls will call it, in the handshake, after the certificate request message has been received. This callback function will only be called when the server ask for a client certificate during the handshake, but weechat also use this callback to check the server certificate. As specified in the rfc2246 at 7.4.6., the certificate request is optionnal: 7.4.6. Client certificate When this message will be sent: This is the first message the client can send after receiving a server hello done message. This message is only sent if the server requests a certificate. So when the server does not request a client certificate, hook_connect_gnutls_set_certificates is never called and weechat does not perform any check on the server certificate. It doesn't print any of the usual information about the dh key size and the content of the server certificate either. POC: $ openssl genrsa -out server.key 4096 $ openssl req -new -key server.key -out server.csr $ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt $ openssl dhparam -outform PEM -out dhparam.pem 4096 $ openssl s_server -cert server.crt -key server.key -dhparam dhparam.pem -accept 6697 &>./log & $ weechat-curses ircs://127.0.0.1:6697 # will not check the certificate $ fg ^C $ openssl s_server -cert server.crt -key server.key -dhparam dhparam.pem -accept 6697 -verify yes &>./log2 & $ weechat-curses ircs://127.0.0.1:6697 # will print an error because the certificate is self signed This problem affects all versions. The maintainer has been contacted and a fix should be published. someday... A "beta" fix is availaible here: http://savannah.nongnu.org/patch/index.php?7459 JD ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Facebook URL Redirect Vulnerability
-- 1. Summary: Once the victim clicks on a specially crafted Facebook URL they can be redirected to a malicious website. -- 2. Description: Facebook applications use of 'track.php?r=' doesn't sanitize the redirection input properly. This allows an attacker to input any URL that a victim will get redirected too. It is not required for the victim to be login to Facebook for this attack to work. The following is an example of a vulnerable URL: http://apps.facebook.com/truthsaboutu/track.php?r=http://www.securitypentest.com The following Google search query can be used to find vulnerable URLs: site:facebook.com inurl:"track.php?" inurl:"r=" -- 3. Impact: Potentially allow an attacker to compromise a victim’s Facebook account and/or computer system. -- 4. Affected Products: www.facebook.com -- 5. Solution: None -- 6. Time Table: 2/27/2011 Reported Vulnerability to the Vendor -- 7. Credits: Discovered by Nathan Power www.securitypentest.com -- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] III World War. - Broadcast Request.
Hello, To Whom it may concern. I believe that the IIIWorld War conflict might start in 10 months or more from now. The question is: who's unified and who's willing to participate. Leadership is not yet defnied. It may be as well someone well known in IT industry or someone completely unknown. Where we could meet if such situation happens ? It might not happen any time soon so it may sound like hoax but just in case, any ideas ? Security guys must have a plan. Even if it sounds pathetic as for now. So? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] CONFidence 2011- CfP only 6 days left, we are still waiting for your submission
CONFIDENCE 9TH EDITION CALL FOR PAPERS.
/* Apologies if you receive multiple copies of this announcement */
###
If you still consider to become the CONFidence speaker there is only 6
days left to send CfP submission.
Calling all practitioners in the field of IT security!
The 9th edition of the international IT security conference, CONFidence
2011, is taking place in May 24/25, 2011.
We invite all to send the proposed topic and abstracts of presentation
till the 5th March 2011. Please, remember that CONFidence is an open,
international conference and all presentations should be given in English.
The answer to CfP should include:
# name, last name and e-mail address of the potential speaker
# speaker's short bio, describing his experience and skills
# speaker's place of residence
# presentation topic with short description of proposed lecture (no more
than 500 words)
# non-standard technical requirements
We are especially interested in presentation concerning:
# Analysis and reverse engineering of malicious code
# Analysis of vulnerability, attacks and defence against networks,
hardware, software
# Virtualization and operating systems security
# Web applications security and cryptographic
# Botnets
# Security research
Applications should be sent to andrzej.targosz{@}proidea.org.pl till the
5th March, 2011.
DISCLAIMERS
We do not accept marketing, non-technical presentations aimed at
presenting and selling any products. If your lecture presents company or
its product, please do not send it!
SPONSORSHIP
CONFidence offers many sponsorship opportunities. 100% of the
sponsorship goes directly to the attendees. If you are interested in
sponsoring, please contact slawomir.jabs{@}proidea.org.pl
CONFidence conference is a non-profit event and speakers are not being
paid. However, we always try to provide financial help and
cover travel expenses and accommodation. It needs to be agreed upon
after acceptance of the submission, though.
CONFidence Team
http://2011.confidence.org.pl
--
Andrzej Targosz :1024D/E2DE0833 :gpg: http://www.proidea.org.pl/gpg/at
Fundacja Wspierania Edukacji Informatycznej PROIDEA
ul. Konarskiego 44 lok.6, 30-046 Krakow tel./fax: +4812 6171183
e-mail: andrzej.targ...@proidea.org.pl
JID: andrzej.targ...@jabber.wroc.pl
www.proidea.org.pl
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] buy information or exploit for ZDI-11-075/CVE-2011-0606
buy information or exploit for ZDI-11-075/CVE-2011-0606 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Python ssl handling could be better...
On Feb 28, 2011, at 9:34 AM, Michael Krymson wrote: > > What about self-signed certs in my closed network? The ssl.py module (library/whatever) has support for selectively disabling certificate verification. This parameter should be exposed up the stack in modules that rely on it. The second major problem here is that httplib.py does not support that parameter, so anything higher in the stack is tied to the (incorrect) default. That's the thing with default behaviors: The default should be set to something sane (in the case of encryption, SECURE) and there should be a way to override it if a significant number of users will want to do so (two strikes against the Python dev team). BTW there really isn't a security difference between encrypted-but-unauthenticated traffic and just plain unencrypted traffic. The only "attacker" you're defeating is a casual observer, who probably is more curious than harmful. Determined attackers who are out to harm you are going to get the information any way. If something is important enough to encrypt traffic to/from, it's important enough to authenticate too, otherwise it isn't worth the hassle at all. > What about guests on a network behind a web proxy that MITMs 80/443? If you're intentionally MITM client traffic, the client should trust your MITM CA. If you aren't doing it that way, ur doin it rong. You basically just compromised the security of all of your end-points and are training your users to ignore warnings. In the case of Python apps, you're teaching your developers insecure coding practices. It's cascading stupidity. > What if you're brokering a connection, not for some strict security sake, but > just because you can and gain a little bit of privacy? Have any personal web > sites/servers you don't *need* commercial certs for but want something anyway? See above. > > In an ideal world, I hear what you're saying. But we're far from ideal... It's not ideal because people take the lazy way and assume that unauthenticated encryption is "good enough." It's not good enough because it's trivially broken. It used to be (say, a decade ago) less risky because there weren't readily available tools everywhere that could do the active MITM, but now there are and everyone has already learned to be lazy, so we're at a net deficit from the starting point. Every time you tell yourself "it could be broken, but I'm sure no one will make that much of an effort" you're wrong and just made a fundamental mistaken. > > I think we should be happy with the inclusion of such options in 3.2 No, I'm not going to be happy about an after-thought fix. At least httplib.py should never have been put in the tree without an option to tell ssl.py to verify the server cert. FFS they have client cert support, would it REALLY be that hard to pass the verification parameter to ssl.py? No, it's just sheer ignorance of security. -- bk ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] III World War. - Broadcast Request.
>I believe that the IIIWorld War conflict might start in 10 months or more from >now. The question is: who's unified and who's willing to participate. >Leadership is not yet defnied. It may be as well someone well known in IT >industry or someone completely unknown. > >Where we could meet if such situation happens ? That depends on your concept of "heaven." t ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] III World War. - Broadcast Request.
I'm already living on a rock completely insulated from the rest of mankind. What about you? On Mon, Feb 28, 2011 at 9:39 PM, Thor (Hammer of God) wrote: > >I believe that the IIIWorld War conflict might start in 10 months or more > from > >now. The question is: who's unified and who's willing to participate. > >Leadership is not yet defnied. It may be as well someone well known in IT > >industry or someone completely unknown. > > > >Where we could meet if such situation happens ? > > That depends on your concept of "heaven." > t > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] III World War. - Broadcast Request.
> I believe that the IIIWorld War conflict might start in 10 months or > more from now. It's hard to disagree. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] III World War. - Broadcast Request.
On Sat, 26 Feb 2011 00:31:47 +0100, asmo said: > I believe that the IIIWorld War conflict might start in 10 months or > more from now. The question is: who's unified and who's willing to > participate. > Leadership is not yet defnied. It may be as well someone well known in > IT industry or someone completely unknown. Almost certainly *not* lead by anybody well known in the IT industry. Basically, if you manage to start a world war, you're almost by definition going to have at least two of the permanent members of the UN Security Council getting on your case (if only one of the five shows up, you've only managed a regional skirmish, not a world war). If you get *lucky*, you get France and the UK militaries beating up on you. If you're unlucky, one or more of (US, Russia, China) are going to come looking for you as well. There's very few IT organizations that have enough military might to pull that off. (Let's face it guys - if you can't survive the entire 82nd Airborne dropping in for lunch and live-fire practice, you're not ready to start a world war.) And you can rule WWIII == cyberwar right out - the world is interconnected enough that cyberwar on a "world war" scale is a Bad Idea for the same reason biological weapons are - it comes back to haunt you. You may be able to create a lot of havoc with a cyber attack, but creating enough havoc in any world-power nation to constitute "victory" is almost certainly going to screw your *own* country over as well. Consider the recent global economic crisis as an example - you'd need an event much bigger and messier than that. And there's pretty much noplace on earth that's big and high tech enough to launch that sort of thing and yet not interconnected enough to avoid the backlash. (That is, of course, also why no cybercriminals have nuked the internet yet - the ones smart enough to do it are also smart enough to realize that doing so kills their profit margin). Biggest danger right now - civil wars from Libya to Pakistan, with perhaps as many as 400 nuclear warheads in play (around 80-100 each for India, Pakistan, and Israel, and 100 or so illicit warheads from the former Soviet Union in the hands of various government and non-government actors). That *could* evolve into a mess big enough to qualify as a World War, but only because there *won't* be anybody leading it. tl;dr: Cool story, bro. pgpURt8RNum2y.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] III World War. - Broadcast Request.
ahahaahah...what kind of haze did you smoke this time Mr. asmo? Take it easy with drugs :) antisnatchor Christian Sciberras February 28, 2011 10:04 PM I'm already living on a rock completely insulated from the rest of mankind. What about you? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Thor (Hammer of God) February 28, 2011 9:39 PM That depends on your concept of "heaven." t ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ asmo February 26, 2011 12:31 AM Hello, To Whom it may concern. I believe that the IIIWorld War conflict might start in 10 months or more from now. The question is: who's unified and who's willing to participate. Leadership is not yet defnied. It may be as well someone well known in IT industry or someone completely unknown. Where we could meet if such situation happens ? It might not happen any time soon so it may sound like hoax but just in case, any ideas ? Security guys must have a plan. Even if it sounds pathetic as for now. So? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [SECURITY] [DSA 2175-1] samba security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2175-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff February 28, 2011 http://www.debian.org/security/faq - - Package: samba Vulnerability : missing input sanisiting Problem type : remote Debian-specific: no CVE ID : CVE-2011-0719 Volker Lendecke discovered that missing range checks in Samba's file descriptor handling could lead to memory corruption, resulting in denial of service. For the oldstable distribution (lenny), this problem has been fixed in version 3.2.5-4lenny14. For the stable distribution (squeeze), this problem has been fixed in version 3.5.6~dfsg-3squeeze2. For the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your samba packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1rrh4ACgkQXm3vHE4uylpmpwCcClO0yLoAzc1mEG0pLIPk1qmB V/cAn1zbcsaGNlw/i+bERiogVCwDDXz2 =1+6X -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] ZDI-11-094: (0 day) Hewlett-Packard StorageWorks File Migration Agent Remote Archive Tampering Vulnerability
ZDI-11-094: (0 day) Hewlett-Packard StorageWorks File Migration Agent Remote Archive Tampering Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-11-094 February 28, 2011 -- CVSS: 7.5, (AV:N/AC:L/Au:N/C:P/I:P/A:P) -- Affected Vendors: Hewlett-Packard -- Affected Products: Hewlett-Packard StorageWorks -- TippingPoint(TM) IPS Customer Protection: TippingPoint IPS customers have been protected against this vulnerability by Digital Vaccine protection filter ID 10854. For further product information on the TippingPoint IPS, visit: http://www.tippingpoint.com -- Vulnerability Details: This vulnerability allows remote attackers to compromise the archive records on vulnerable installations of HP StorageWorks File Migration Agent. Authentication is not required to exploit this vulnerability. The specific flaw exists within the HsmCfgSvc.exe service responsible for managing archive stores. The archive manager is susceptible to tampering due to a failure to enforce authentication from remote users. An attacker could exploit this flaw to compromise the server managing the archives and arbitrarily modify the archive data store under the context of the File Migration Agent software. -- Vendor Response: February 23, 2011 - This vulnerability is being disclosed publicly without a patch in accordance with the ZDI 180 day deadline. --Mitigations: The overall design of the File Migration Agent (FMA) assumes it runs as an application on a Windows server. Given the stated purpose of FMA, and the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the service to trusted machines. Only the clients and servers that have a legitimate procedural relationship with the HP StorageWorks File Migration Agent should be permitted to communicate with it. This could be accomplished in a number of ways, most notably with firewall rules/whitelisting. These features are available in the native Windows Firewall, as described in http://technet.microsoft.com/en-us/library/cc725770%28WS.10%29.aspx and numerous other Microsoft Knowledge Base articles. -- Disclosure Timeline: 2010-08-25 - Vulnerability reported to vendor 2011-02-28 - Coordinated public release of advisory -- Credit: This vulnerability was discovered by: * AbdulAziz Hariri -- About the Zero Day Initiative (ZDI): Established by TippingPoint, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. Researchers interested in getting paid for their security research through the ZDI can find more information and sign-up at: http://www.zerodayinitiative.com The ZDI is unique in how the acquired vulnerability information is used. TippingPoint does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, TippingPoint provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, TippingPoint provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product. Our vulnerability disclosure policy is available online at: http://www.zerodayinitiative.com/advisories/disclosure_policy/ Follow the ZDI on Twitter: http://twitter.com/thezdi ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [USN-1078-1] Logwatch vulnerability
=== Ubuntu Security Notice USN-1078-1March 01, 2011 logwatch vulnerability CVE-2011-1018 === A security issue affects the following Ubuntu releases: Ubuntu 8.04 LTS Ubuntu 9.10 Ubuntu 10.04 LTS Ubuntu 10.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 8.04 LTS: logwatch7.3.6-1ubuntu1.1 Ubuntu 9.10: logwatch7.3.6.cvs20090906-1ubuntu1.1 Ubuntu 10.04 LTS: logwatch7.3.6.cvs20090906-1ubuntu2.1 Ubuntu 10.10: logwatch7.3.6.cvs20090906-1ubuntu3.1 In general, a standard system update will make all the necessary changes. Details follow: Dominik George discovered that logwatch did not properly sanitize log file names that were passed to the shell as part of a command. If a remote attacker were able to generate specially crafted filenames (for example, via Samba logging), they could execute arbitrary code with root privileges. Updated packages for Ubuntu 8.04 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6-1ubuntu1.1.diff.gz Size/MD5:15656 31f40f13457aeb20f21c2cfd2ad460b8 http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6-1ubuntu1.1.dsc Size/MD5: 1413 037612770004ad6b553b8c5b02840350 http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.orig.tar.gz Size/MD5: 297296 937d982006b2a76a83edfcfd2e5a9d7d Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6-1ubuntu1.1_all.deb Size/MD5: 307458 da69f492898cee9560bb752b87e8af1c Updated packages for Ubuntu 9.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-1ubuntu1.1.diff.gz Size/MD5:87133 eb1efb5614967c87dcee5a0627db91a2 http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-1ubuntu1.1.dsc Size/MD5: 1932 b32ef1d8ada8a539c73a6e8da732a7c8 http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906.orig.tar.gz Size/MD5: 338115 b12229916e0a5891a8c1da59afb61e40 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-1ubuntu1.1_all.deb Size/MD5: 400012 6a943f596ed79064930b328a7058357e Updated packages for Ubuntu 10.04 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-1ubuntu2.1.diff.gz Size/MD5:87803 0bba6a4701307c1abb9fea16c15c11fd http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-1ubuntu2.1.dsc Size/MD5: 1932 d87291a904f97e6c13dc15f0c996eeb4 http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906.orig.tar.gz Size/MD5: 338115 b12229916e0a5891a8c1da59afb61e40 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-1ubuntu2.1_all.deb Size/MD5: 401512 d68a24ddbbfde6880fdbff79290bf344 Updated packages for Ubuntu 10.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-1ubuntu3.1.diff.gz Size/MD5:90181 971dda35e4fa086a1bab9b9d7814a0df http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-1ubuntu3.1.dsc Size/MD5: 1932 388d1296df12dc1f46d0ddebfe6bf6ae http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906.orig.tar.gz Size/MD5: 338115 b12229916e0a5891a8c1da59afb61e40 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-1ubuntu3.1_all.deb Size/MD5: 398960 d7967323e366778cc5c79701aa1dc156 signature.asc Description: Digital signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [PSRT] Python ssl handling could be better...
On Feb 28, 2011, at 10:37 AM, bk wrote: >> I think we should be happy with the inclusion of such options in 3.2 > >No, I'm not going to be happy about an after-thought fix. At least >httplib.py should never have been put in the tree without an option to tell >ssl.py to verify the server cert. FFS they have client cert support, would >it REALLY be that hard to pass the verification parameter to ssl.py? No, >it's just sheer ignorance of security. Maybe I missed it, but do you have a specific patch you want us to review? As for back porting to stable release versions, that will have to be determined by the release managers for each version, and that can only be done once there are actual patches we can look at. All versions of Python prior to 3.3 are now in stable release mode, so (speaking as the Python 2.6 RM) patches that add new features or change API just can't be accepted. I'm skeptical, but if there are backward compatible changes that can be added as a bug fix to Python 3.2 or 2.7, those might be considered. The best way to handle the situation in that case is: * Develop a patch for Python 3.3 which includes unit tests and documentation, get it reviewed, and lobby the Python community for inclusion in 3.3. * Back port the changes to a standalone library for earlier versions of Python and release these on the Cheeseshop. * Evangelize these separate packages for users who want the full security of authenticated encrypted channels. Please understand that these policies have been in place for many years and we adhere to them after many hard lessons learned. -Barry signature.asc Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
