[Full-disclosure] [SECURITY] [DSA 2362-1] acpid security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2362-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff December 10, 2011 http://www.debian.org/security/faq - - Package: acpid Vulnerability : several Problem type : remote Debian-specific: partly CVE ID : CVE-2011-1159 CVE-2011-2777 CVE-2011-4578 Multiple vulnerabilities were found in the acpid, the Advanced Configuration and Power Interface event daemon: CVE-2011-1159 Vasiliy Kulikov of OpenWall discovered that the socket handling is vulnerable to denial of service. CVE-2011-2777 Oliver-Tobias Ripka discovered that incorrect process handling in the Debian-specific powerbtn.sh script could lead to local privilege escalation. This issue doesn't affect oldstable. The script is only shipped as an example in /usr/share/doc/acpid/examples. See /usr/share/doc/acpid/README.Debian for details. CVE-2011-4578 Helmut Grohne and Michael Biebl discovered that acpid sets a umask of 0 when executing scripts, which could result in local privilege escalation. For the oldstable distribution (lenny), this problem has been fixed in version 1.0.8-1lenny4. For the stable distribution (squeeze), this problem has been fixed in version 1:2.0.7-1squeeze3. For the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your acpid 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.11 (GNU/Linux) iEYEARECAAYFAk7jMMMACgkQXm3vHE4uylpE1wCgzAGz7OTYHqPhuf1GVeQLizhh s3EAoJ5PA+xv94YnKeic+HkFVEGmqKjS =t4wv -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/
Re: [Full-disclosure] Google open redirect
Marsh Ray ma...@extendedsubset.com wrote: On 12/08/2011 12:37 AM, Michal Zalewski wrote: For time being, if you make security decisions based on onmouseover tooltips, link text, or anything along these lines, and do not examine the address bar of the site you are ultimately interacting with, there is very little any particular web application can do to save you: you are just at a significant risk wherever you go. If you take away open redirectors, a myriad of other, comparable ways to fool you remain, and can't be fixed easily. I think reasoning based on this is subtly fallacious and it often contributes to disagreements between researchers and large vendors. This is how we got into the state of the web today: bad faith on the part of browser vendors. [...] Avoiding security improvements because the are perceived as being of little benefit to type typical user is wrong. Doing so gains nothing for the typical users, it decreases the security available to competent and contientious users, and worst of all it actively removes any incentives for the typical user to begin to take responsibility for their own security. I'm not sure I understand whether you're saying that vendors need to make users expectations match reality, or if users need to learn how to make security decisions properly. I think it's a believable claim that a large number of users have (incorrectly) decided that they can make security decisions using the status text or the appearance of a URL anywhere other than the address bar. I would be in favour of making that expectation match reality, but it's simply technically infeasible due to a number of fundamental computer science problems. The reality is that pleading with everyone in the world to stop using redirection wouldn't solve the problem, and (in my opinion) is much harder than trying to find these users and educating them about how to achieve the desired effect correctly. Trying to call open redirection a vulnerability strikes me as hilarious. An attacker that can make a user visit an arbitrary URL can make a user visit an arbitrary URL Well, there's no vulnerability there, so let's revise it. An attacker that can make a user visit a URL from a domain they trust can make a user visit a URL from a domain they don't trust. Okay, but there's no way to determine if a URL is trusted or not unless you read it from the address bar. HTTP redirection doesnt do this, as the address bar is correctly updated, so let's revise again. An attacker that can make a user who doesn't know how to determine if a URL is trusted or not visit an arbitrary URL, can convince a user to trust an arbitrary URL. Well obviously :-) But now if we successfully convince every developer on the planet to stop using HTTP redirection, that doesn't change that the user doesnt know how to determine if the URL is trusted or not, so we just use one of dozens of other simple tricks. Surely the correct solution is to educate those users who are doing it incorrectly. Tavis. -- - tav...@cmpxchg8b.com | pgp encrypted mail preferred --- ___ 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] [CFP] FRHACK Africa 2012 Call For Papers
[CFP] FRHACK Africa 2012 Call For Papers
,.
. :%%%..%%%.
__%%%(\`% .%
/a ^ '% %: ,% %%`
'__.. ,'% .-%: %-'%
~~%:. ` % ' . `.
%% % ` %% .%: . \.
%%:. `-' `.%% . %: :\
%(%,%... `%, %%' %% ) )
%)%%)%%' )%%%.- ' / (
%a:f%%\ % / \`% %%% ` / \))
%(%' % /-. \ ' \ |-. '.
`'|% `() \| `()
||/ () /
() 0| o
\ /\o /
o `/-|
,-/ ` ,-/
++
+ FRHACK Africa
+ Call For Papers
+ June 1-2, 2012, Casablanca, Morocco, Africa
+ http://www.frhack.org
++
None but ourselves can free our minds, Bob Marley
[ - Introduction - ]
FRHACK is an International IT Security Conference
FRHACK is not commercial - but - highly technical.
Target Audience: Security Officers, Security Professionals and Product
Vendors, IT Decision Makers, Policy Makers, Security-, Network-, and
Firewall Administrators, Teachers, Academic Researchers and Software
Developers, hackers...
The FRHACK Team (TFT) encourages speakers to present new and interesting
projects for FRHACK and will give preferential treatment to
submissions that have not been presented at other conferences.
Further, TFT invites any individual who has not spoken at a conference
before to submit a talk and attempt to make FRHACK their inaugural event!
Papers should be submitted in English.
The conference language is English.
(Anyway, papers in Arabic or French are accepted for special post-event
tracks.)
Conference will be held in Casablanca, Morocco, North of Africa,
and aims to get together industry, government, academia and
underground hackers to share knowledge and leading-edge ideas about
information security and everything related to it.
FRHACK will feature national and international speakers and attendees
with a wide range of skills.
The atmosphere is favorable to present all facets of computer security
subject and will be a great opportunity to network with like-minded
people and enthusiasts.
[ - The venue - ]
Don't forget your Humphrey Bogart's style black hat while coming to
Casablanca.
Casablanca ('White House') is Morocco's largest city as well as its
chief port.
It is also the biggest city in the Maghreb.
https://en.wikipedia.org/wiki/Casablanca
Did you know that Arabic is the fastest growing language in the Web?
http://wikileaks.org/spyfiles/files/0/71_201110-ISS-IAD-T5-SCAN_AND_TARGET.pdf
More information soon available at http://www.frhack.org
[ - Topics - ]
TFT gives preference to lectures with practical demonstration. The
conference staff will try to provide every equipment needed for the
presentation in the case the author cannot provide them.
The following topics include, but are not limited to:
- Rootkits
- Cryptography
- Cloud security
- Reverse engineering
- Penetration testing
- Web application security
- Exploit development techniques
- Internet, privacy and Big Brother
- Telecom security and phone phreaking
- Fuzzing and application security test
- Security in Wi-Fi and VoIP environments
- Information warfare and industrial espionage
- Denial of service attacks and/or countermeasures
- Analysis of virus, worms and all sorts of malwares
- Technical approach to alternative operating systems
- Techniques for development of secure software systems
- Information about smartcard and RFID security and similars
- Lockpicking, trashing, physical security and urban exploration
- Hardware hacking, embedded systems and other electronic devices
- Mobile devices exploitation, Android, iOS, 3/4G and other
technologies
- Security aspects in SCADA, industrial environments and obscure
networks
[ - Important dates - ]
Conference and trainings
20120530-31: FRHACK trainings
20120601-02: FRHACK conferences
Linkedin group:
http://www.linkedin.com/groups?gid=1613377
Deadline and submissions
- Deadline for proposal submissions: 20120331
- Deadline for slides submissions: 20120512
- Notification of acceptance or rejection: 20120430
* E-mail for proposal submissions: c...@frhack.org *
Make sure to provide along with your submission the following details:
- Speaker name and/or nickname, address, e-mail, phone number and
general contact information
- A brief but informative description about your talk
- Short biography of the presenter, including organization, company
and affiliations
-
[Full-disclosure] silly PoCs continue: X-Frame-Options give you less than expected
At the risk of annoying everyone... I think we greatly underappreciate the extent to which JavaScript allows you to exploit the limits of human perception. On modern high-performance systems, windows can be opened, positioned, and closed; and documents loaded and then navigated away from; so quickly that we can't even reliably notice that, let alone react consciously. The PoC I posted here earlier this week (http://lcamtuf.coredump.cx/switch/) demonstrates one example of page transitions occurring so fast that you don't register it; and some of my earlier posts outlined the exploitation of page switching to exploit browser UIs (e.g. http://lcamtuf.coredump.cx/ffgeo2/). Today, I wanted to share this brief demonstration of an attack that should hopefully illustrate why our current way of thinking about clickjacking (and the possible defenses, such as X-Frame-Options) is flawed: http://lcamtuf.coredump.cx/clickit/ The basic idea here is that instead of placing the UI you want to tamper with in an invisible or only partly-visible iframe, you can achieve a similar effect simply by predicting the time of a premeditated click (which is fairly easy if you look at mouse velocity and distance to the expected destination), and then either destroying the current window, or navigating to a different document (in this case, a cheesy banking site). While everything about this exploit is extremely goofy, and I put no effort into making the transitions less obvious, it should still demonstrate the issue neatly. /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] silly PoCs continue: X-Frame-Options give you less than expected
Its awesome ... and works, but, yes conditions must be met for firefox8 still... this is 2011 ;s almost 12! this is, i guess a great PoC and info but, only some ppl realise the potentiall to this anyhow, thanks Mike,thats a GREAT job mate :) /xd On 11 December 2011 09:39, Michal Zalewski lcam...@coredump.cx wrote: At the risk of annoying everyone... I think we greatly underappreciate the extent to which JavaScript allows you to exploit the limits of human perception. On modern high-performance systems, windows can be opened, positioned, and closed; and documents loaded and then navigated away from; so quickly that we can't even reliably notice that, let alone react consciously. The PoC I posted here earlier this week (http://lcamtuf.coredump.cx/switch/) demonstrates one example of page transitions occurring so fast that you don't register it; and some of my earlier posts outlined the exploitation of page switching to exploit browser UIs (e.g. http://lcamtuf.coredump.cx/ffgeo2/). Today, I wanted to share this brief demonstration of an attack that should hopefully illustrate why our current way of thinking about clickjacking (and the possible defenses, such as X-Frame-Options) is flawed: http://lcamtuf.coredump.cx/clickit/ The basic idea here is that instead of placing the UI you want to tamper with in an invisible or only partly-visible iframe, you can achieve a similar effect simply by predicting the time of a premeditated click (which is fairly easy if you look at mouse velocity and distance to the expected destination), and then either destroying the current window, or navigating to a different document (in this case, a cheesy banking site). While everything about this exploit is extremely goofy, and I put no effort into making the transitions less obvious, it should still demonstrate the issue neatly. /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/ ___ 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] silly PoCs continue: X-Frame-Options give you less than expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/2011 22:39, Michal Zalewski wrote: At the risk of annoying everyone... I think we greatly underappreciate the extent to which JavaScript allows you to exploit the limits of human perception. On modern high-performance systems, windows can be opened, positioned, and closed; and documents loaded and then navigated away from; so quickly that we can't even reliably notice that, let alone react consciously. The PoC I posted here earlier this week (http://lcamtuf.coredump.cx/switch/) demonstrates one example of page transitions occurring so fast that you don't register it; and some of my earlier posts outlined the exploitation of page switching to exploit browser UIs (e.g. http://lcamtuf.coredump.cx/ffgeo2/). Today, I wanted to share this brief demonstration of an attack that should hopefully illustrate why our current way of thinking about clickjacking (and the possible defenses, such as X-Frame-Options) is flawed: http://lcamtuf.coredump.cx/clickit/ The basic idea here is that instead of placing the UI you want to tamper with in an invisible or only partly-visible iframe, you can achieve a similar effect simply by predicting the time of a premeditated click (which is fairly easy if you look at mouse velocity and distance to the expected destination), and then either destroying the current window, or navigating to a different document (in this case, a cheesy banking site). While everything about this exploit is extremely goofy, and I put no effort into making the transitions less obvious, it should still demonstrate the issue neatly. /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/ Looks Like I won Michal. Where's my prize? Clever stuff. This kind of thing has occurred to me as system and indeed network/broadband speed have increased. One time a flashing of a neon on a router or modem or the a flash of a window on a desktop gave some indication of data ingress or egress. Nowadays it's done and over with before the user even realises something is afoot. I had to enable Javascript though. I guess I trust you not to burn my ass. There are not many links posted on this list which I would click with javascript enabled. Thanks for your insights and the education Dave -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBTuPrVrIvn8UFHWSmAQJcJAgAqtAh+2LMzLOefwX31DZRNtoMgjWRt2yc 5CxN6uhnli97D9qJWDYOBYWJhO0/IV9zxmdVdQ5Pt+4LxPz2ollUFHbzD5vIWUd/ bYVE5x+cWgt8ZCRbJD5VNZcxYP4QsqRYlVspPcVjeVqKV26qYbCMPF83c/OtNiuR wZq/RmsJHrLWydFbNQfDGI/ufnwYLJEiH4GwqHxIjsajLOqBGztxPcWkIkfDDDQd tbPx49JF8e04aXqdAZlGxFV/sKTJVhaKsKPbUYiVGZF/vYbcFFO3eKF0s39hbBND 5rLH1qmEfzaC799bCZ/8tT/2/EA4xtZjJGrwzyNjA84eEL0J9g2PCw== =10aN -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] [ MDVSA-2011:183 ] pidgin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2011:183 http://www.mandriva.com/security/ ___ Package : pidgin Date: December 10, 2011 Affected: 2010.1, 2011., Enterprise Server 5.0 ___ Problem Description: Multiple vulnerabilities has been discovered and corrected in pidgin: When receiving various stanzas related to voice and video chat, the XMPP protocol plugin failed to ensure that the incoming message contained all required fields, and would crash if certain fields were missing. When receiving various messages related to requesting or receiving authorization for adding a buddy to a buddy list, the oscar protocol plugin failed to validate that a piece of text was UTF-8. In some cases invalid UTF-8 data would lead to a crash (CVE-2011-4601). When receiving various incoming messages, the SILC protocol plugin failed to validate that a piece of text was UTF-8. In some cases invalid UTF-8 data would lead to a crash (CVE-2011-3594). This update provides pidgin 2.10.1, which is not vulnerable to these issues. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4601 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3594 http://www.pidgin.im/news/security/ http://pidgin.im/news/security/?id=56 http://pidgin.im/news/security/?id=57 http://pidgin.im/news/security/?id=58 ___ Updated Packages: Mandriva Linux 2010.1: 5760fb2021c3bcd9a9cc868c4d372ed9 2010.1/i586/finch-2.10.1-0.1mdv2010.2.i586.rpm c3780080c901d37497d05a64ad04861c 2010.1/i586/libfinch0-2.10.1-0.1mdv2010.2.i586.rpm 44dab21da24dc0cbe87aa77cc169284c 2010.1/i586/libpurple0-2.10.1-0.1mdv2010.2.i586.rpm 8a02d670933e11151ed49c836dc8e7fb 2010.1/i586/libpurple-devel-2.10.1-0.1mdv2010.2.i586.rpm e5565acb778b22f18c58d9f58936904d 2010.1/i586/pidgin-2.10.1-0.1mdv2010.2.i586.rpm 8d7dd47702343d6faf2cb8fc37905cb3 2010.1/i586/pidgin-bonjour-2.10.1-0.1mdv2010.2.i586.rpm aee6e7d5b101af04a3d1bb565de1a48f 2010.1/i586/pidgin-client-2.10.1-0.1mdv2010.2.i586.rpm 6d6e5c647e0c88b8aec6044f13e3616c 2010.1/i586/pidgin-gevolution-2.10.1-0.1mdv2010.2.i586.rpm 70b22a04176ec1e5240b4e43722cede3 2010.1/i586/pidgin-i18n-2.10.1-0.1mdv2010.2.i586.rpm 6673de268a4c53b44dae91487944c211 2010.1/i586/pidgin-meanwhile-2.10.1-0.1mdv2010.2.i586.rpm 6862f6fc918cca0d60a162e9c160e452 2010.1/i586/pidgin-perl-2.10.1-0.1mdv2010.2.i586.rpm 754903e35ac3b0e77d2c13e846dbdc41 2010.1/i586/pidgin-plugins-2.10.1-0.1mdv2010.2.i586.rpm 2e16473bc98b8f4dda76b89b44690322 2010.1/i586/pidgin-silc-2.10.1-0.1mdv2010.2.i586.rpm fd8a4eb06e140550966e9d4dd47e8647 2010.1/i586/pidgin-tcl-2.10.1-0.1mdv2010.2.i586.rpm 67da842fb1886685ed1f9d1a2811ca41 2010.1/SRPMS/pidgin-2.10.1-0.1mdv2010.2.src.rpm Mandriva Linux 2010.1/X86_64: 19214e80ad6e07bc8fbd76a770f5fb41 2010.1/x86_64/finch-2.10.1-0.1mdv2010.2.x86_64.rpm b5fc8b19bc3566a9845e44e63ca91cd3 2010.1/x86_64/lib64finch0-2.10.1-0.1mdv2010.2.x86_64.rpm 9465e855935e5f1a1159824ca3529080 2010.1/x86_64/lib64purple0-2.10.1-0.1mdv2010.2.x86_64.rpm 5d8608f39db8a0888c05ebd592dee061 2010.1/x86_64/lib64purple-devel-2.10.1-0.1mdv2010.2.x86_64.rpm 7adaa941cd2bca0445e112f0d2a35f16 2010.1/x86_64/pidgin-2.10.1-0.1mdv2010.2.x86_64.rpm 56a3a11402f7397ba723cf341f7ff73c 2010.1/x86_64/pidgin-bonjour-2.10.1-0.1mdv2010.2.x86_64.rpm e9877b42a24ad67f1c90a959809f543b 2010.1/x86_64/pidgin-client-2.10.1-0.1mdv2010.2.x86_64.rpm 55a597ea9298a7a34ce1c086982eb557 2010.1/x86_64/pidgin-gevolution-2.10.1-0.1mdv2010.2.x86_64.rpm 55461139c45ddb5851336ddcf0e89dab 2010.1/x86_64/pidgin-i18n-2.10.1-0.1mdv2010.2.x86_64.rpm 0a092014c245cf7b258e83308ab12b4a 2010.1/x86_64/pidgin-meanwhile-2.10.1-0.1mdv2010.2.x86_64.rpm 718579ad386213ebd9c73c9a4d2810db 2010.1/x86_64/pidgin-perl-2.10.1-0.1mdv2010.2.x86_64.rpm bb044452a207e7df0ef1eb836c13c432 2010.1/x86_64/pidgin-plugins-2.10.1-0.1mdv2010.2.x86_64.rpm d16a10cd074364d4a9a97e435cfe0b28 2010.1/x86_64/pidgin-silc-2.10.1-0.1mdv2010.2.x86_64.rpm 0b2cdfb643d2efb098c50e708f900f79 2010.1/x86_64/pidgin-tcl-2.10.1-0.1mdv2010.2.x86_64.rpm 67da842fb1886685ed1f9d1a2811ca41 2010.1/SRPMS/pidgin-2.10.1-0.1mdv2010.2.src.rpm Mandriva Linux 2011: 9b78a3cb5192b6b973715a86d5f2a185 2011/i586/finch-2.10.1-0.1-mdv2011.0.i586.rpm 4d883b1daddce33fafe57d9a99463358 2011/i586/libfinch0-2.10.1-0.1-mdv2011.0.i586.rpm 499ca1bc78a3f2df77e88e2703a4a725 2011/i586/libpurple0-2.10.1-0.1-mdv2011.0.i586.rpm b6948cabf0fcd0c3dd104219bf4d529b 2011/i586/libpurple-devel-2.10.1-0.1-mdv2011.0.i586.rpm 0016330f267d2bff69e61713c44699ed
Re: [Full-disclosure] silly PoCs continue: X-Frame-Options give you less than expected
Interesting stuff indeed. However, I don't see you talk about a solution. Why is that? Because it's bugtraq / full-disclosure, where people generally talk about vulnerabilities... I'm not sure I follow your drift about Firefox, I don't believe it's mentioned anywhere. Anyhow, correct me if I'm wrong, but this concept won't work when the attacked site requires multiple user interaction, right? As in, the user will notice something amiss the second time. Why? /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/
