[Full-disclosure] cfp: TRsec, Istanbul Turkey
TRsec is a security and hacking conference happening September 8th, 2007, in Istanbul, Turkey. Details --- TRsec is a security conference for the Turkish security industry. It is organized by the Profilo group in cooperation with Beyond Security. Goal Bring a technical security conference to Turkey, its security industry and local professionals. Call for Papers information --- Topics to submit for this conference include: Malware, intrusion detection, corporate security, risk assessment, reverse engineering, network security, etc. Meaning - any security subject. Preference will be given to technical security talks. To submit email me personally at: [EMAIL PROTECTED] Location TRsec will take place at PROFLO ALIVER MERKEZ (http://www.pam.com.tr/pam/index.php), starting at 9 AM, on the 8th of September. Thanks, Gadi Evron, Beyond Security. ___ 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 1349-1] New libextractor packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1349-1[EMAIL PROTECTED] http://www.debian.org/security/ Moritz Muehlenhoff August 5th, 2007http://www.debian.org/security/faq - -- Package: libextractor Vulnerability : integer overflow Problem type : local (remote) Debian-specific: no CVE ID : CVE-2007-3387 It was discovered that an integer overflow in the xpdf PDF viewer may lead to the execution of arbitrary code if a malformed PDF file is opened. libextractor includes a copy of the xpdf code and required an update as well. For the oldstable distribution (sarge) this problem has been fixed in version 0.4.2-2sarge6. The stable distribution (etch) isn't affected by this problem. The unstable distribution (sid) isn't affected by this problem. We recommend that you upgrade your libextractor 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 at the end of this advisory: 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/libe/libextractor/libextractor_0.4.2-2sarge6.dsc Size/MD5 checksum: 778 fbcbd62c772674dc96a26373e5aa6e01 http://security.debian.org/pool/updates/main/libe/libextractor/libextractor_0.4.2-2sarge6.diff.gz Size/MD5 checksum: 9063 bb026f68189fd93686e5fd94b6cda88e http://security.debian.org/pool/updates/main/libe/libextractor/libextractor_0.4.2.orig.tar.gz Size/MD5 checksum: 5887095 d99e1b13a017d39700e376a0edbf7ba2 Alpha architecture: http://security.debian.org/pool/updates/main/libe/libextractor/extract_0.4.2-2sarge6_alpha.deb Size/MD5 checksum:19690 01b435b2688d03f3459c79526954925c http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1_0.4.2-2sarge6_alpha.deb Size/MD5 checksum: 5810714 dd23f39e0b388296b1fc271739712ebe http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1-dev_0.4.2-2sarge6_alpha.deb Size/MD5 checksum:19484 7f05a34e53fd43830028912e14d2328f AMD64 architecture: http://security.debian.org/pool/updates/main/libe/libextractor/extract_0.4.2-2sarge6_amd64.deb Size/MD5 checksum:18346 b0630efe8af750547c51f18e2b37e56c http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1_0.4.2-2sarge6_amd64.deb Size/MD5 checksum: 5641608 6cc4c3570ed2c3319944d2dadeb32df2 http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1-dev_0.4.2-2sarge6_amd64.deb Size/MD5 checksum:17618 b03292795065cdd0c9444343f216a058 ARM architecture: http://security.debian.org/pool/updates/main/libe/libextractor/extract_0.4.2-2sarge6_arm.deb Size/MD5 checksum:17726 b7d8e767fdec15d9f1dd42a4d287d093 http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1_0.4.2-2sarge6_arm.deb Size/MD5 checksum: 5710926 010de9d5ca245ecde20850f2077ec525 http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1-dev_0.4.2-2sarge6_arm.deb Size/MD5 checksum:17034 70da5564ca690372c8ff2f920e3145e7 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/libe/libextractor/extract_0.4.2-2sarge6_i386.deb Size/MD5 checksum:17870 34c81aebd99358f6a6668e6a6e766dcf http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1_0.4.2-2sarge6_i386.deb Size/MD5 checksum: 5713546 59647b99f778803ae7dd04b8a3ef4f69 http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1-dev_0.4.2-2sarge6_i386.deb Size/MD5 checksum:16796 f6a61702be519be0de6ba5254a8d2bc1 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/libe/libextractor/extract_0.4.2-2sarge6_ia64.deb Size/MD5 checksum:20664 abbab8aca9823e749ce8f56ba180605a http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1_0.4.2-2sarge6_ia64.deb Size/MD5 checksum: 5905678 6c4fae9ee6f98f8a2b04dfc8bb1e6c77 http://security.debian.org/pool/updates/main/libe/libextractor/libextractor1-dev_0.4.2-2sarge6_ia64.deb Size/MD5 checksum:19402 7217989cd00aa203703636a12b73ef1c Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/libe/libextractor/extract_0.4.2-2sarge6_m68k.deb
[Full-disclosure] a couple of notes on Neal Krawetz image forensics presentation
As a bad photographer with several forays into the forensic world, I have a couple of comments on a recent (and pretty interesting!) Black Hat presentation by Neal Krawetz (www.hackerfactor.com) on image forensics: http://blog.wired.com/27bstroke6/files/bh-usa-07-krawetz.pdf To make things clear: I liked it. I think it's solid. I don't want this to be picked up by the press and turned into a food fight. I respect the author. My point is to express my slight doubts regarding several of the far-fetched conclusions presented later in the talk -before the approach is relied upon to fire someone from his post or the like. First things first: in the presentation, following an overview of some of the most rudimentary manual anslysis techniques, Mr. Krawetz employs several mathametical transformations as a method to more accurately detect image tampering. This is based on a valid high-level premise: when lossy formats are repeatedly edited and recompressed, the quality of various portions of the image will proportionally degrade. If the image is composed from a couple of previously lossy compressed files from various sources, their compression degradation patterns may differ - and the current level of degradation can be quantified, in the most rudimentary way simply by measuring how each compression unit (with JPEG, an 8x8px cell) changes with further compression - which is a nonlinear process. The property that makes this possible is known to all photographers - the progressive degradation is the main reason why professional and prosumer photo editing and delivery is done almost exclusively using storage-extensive lossless formats, and why SLR cameras support RAW / TIFF output (and why skilled image forgers would not use lossy formats until they're done, or if forced to, would rescale their work and add subtle noise to thwart analysis). I'm pretty sure the approach is used as one of the inputs by commercial image forensics software, too - along with a couple of other tricks, such as similarity testing to spot the use of clone tool. Now, to the point: the wow factor associated with the presentation and picked up by the press comes from a claim about an apparent heavy manipulation of certain publicly released pictures of Al Qaeda associates, as a proof of the accuracy and reliability of the automated approach - and that's where I'm not really so sure about the conclusions reached. In essence, my issue with this is that the presentation fails to acknowledge that observed patterns do not necessarily depend on the number of saves alone. There are certain very common factors that play a far more pronounced role - and in fact, some of them seem to offer a *better* explanation of some of the artifacts observed. The two most important ones: - Non-uniform subsampling: JPEG and MPEG typically employ 4:2:0 chroma subsampling. This means that a region where a contrast between objects is primarily a product of color changes (at comparable intensity of reflected light) may appear to be older (already lower frequency contrast, producing less pronounced error difference patterns) compared to a region where the same level of contrast can be attributed to luminosity changes alone. Consider this example: http://lcamtuf.coredump.cx/subsampling.png ...we then compress it as a JPEG: http://lcamtuf.coredump.cx/subsampling.jpg ...and can compare the level of compression-related degradation by converting it to cyan-weighted BW: http://lcamtuf.coredump.cx/subsampling_bw.png I attempted to recreate the RGB error difference approach of Mr. Krawetz, resaving it again at a slightly different compression level, and came up with this image, which seems to suggest that only the top text is brand new (comparing this to the conclusions reached for various TV frame grabs later in his presentation, where similar differences in color and contrast were resolved in favor of manipulation): http://lcamtuf.coredump.cx/subsampling_nk.jpg Simply picking out Y component does not help either - since the working space of the editor is inevitably RGB, each resave causes Cb and Cr resampling imprecision to spill to Y on YCbCr - RGB - YCbCr conversions, and introduce errors comparable to what we're trying to detect. - Quantization. JPEG quality is controlled primarily by the accuracy of image quantization step that discards differences in many high-frequency 8x8 patterns, while generally preserving low-frequency ones, but possibly introducing higher-frequency artifacts around more complex shapes, subject to rapid degradation. A good example of this is the following picture: http://blog.wired.com/photos/uncategorized/2007/08/01/ayman_alzawahiri.jpg http://blog.wired.com/photos/uncategorized/2007/08/01/ayman_alzawahiri_analysis.jpg Krawetz attributes the outline around al-Zawahiri seen on the second
Re: [Full-disclosure] a couple of notes on Neal Krawetz image forensics presentation
is neal krawetz phd saying al queda use fake backgrounds in their videos so people don't know they are actually filmed in the whitehouse? neal krawetz is a genuis, i'm a great admirer of his work, he must have lots of girls chasing after him. n3td3v ___ 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] Remote hole in OpenBSD 4.1
I formerly had a great deal of respect, bordering on admiration, for Theo deRaadt's refusals to compromise his open source principles, even in the face of stiff opposition. Although he has occasionally gone over-the-top, recommended some frankly very dubious changes to OpenBSD, and is regularly arrogant (which is even more annoying because he's so often right!), he's always remained consistent in his devotion to the cause of GNU/Free Software. Notice formerly: my confidence in deRaadt has been soundly shaken by his latest round of unfounded aspersions cast against Intel's Core 2 line of CPUs. Instead of getting the facts with careful analysis and study, deRaadt has jumped the gun by trying to preempt proper research with posts to the openbsd-misc mailing list. This in itself wouldn't be so bad, but his only proper citation is a 404 page, and his only other source is an old summary of unverified errata from a hobbyist website. The lack of fact-checking and complete absence of any credible sources for his allegations is suspicious in itself, but he compounds it into a complete boner by making an equally unsupported claim that the supposed (in fact non-existent) CPU problems are security flaws: As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are. Without real references to backup his exaggerated concerns, deRaadt's post crosses the line into outright libel and scare-mongering. It's obvious when you know what to look for: the subtle use of neurolinguistic priming in emotive leading phrases such as some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us, Open source operating systems are largely left in the cold, hiding in this list, and so forth. This does not lead me to share Theo's purported fears; instead it leads me to believe that he's trying to unduly influence Intel's reputation with lies. I have an idea of why. It's the same reason deRaadt feels comfortable in saying that he'd bet a lot of money on Intel's Core 2 processors having multiple (not one, but several) security flaws originating from these errata. Namely, one of Intel's largest competitors has supplied the OpenBSD project with a substantial amount of monetary support since 2004, presumably because they can't compete even in the open source market without propping it up with a flow of money. They cannot maintain their position on the processor front, so they're resorting to buying out open source software developers. It's regrettably cheap to do so, even if they have deRaadt's prestige, because their business models stifle income and so a monolith such as AMD can trivially tempt them with greater incentives. In fact deRaadt is an easier target for donations because he makes it clear that he has no business model for OpenBSD. Intel, by contrast, have no discernable incentive to deceive or play down security flaws in their products; the consecutive f00f and FDIV bugs of the past have taught Intel that their best course of action is to face up to their errors and offer speedy fixes. DeRaadt's claim that Intel must be come [sic] more transparent is most unfounded, especially when one considers who stands to benefit from this anti-Intel arrangement; the connections between the AMD-ATI leviathan and deRaadt-driven projects are not hard to find. AMD make a point of emphasising OpenBSD's place in the AMD64 ecosystem, and, as already mentioned, lends its deep pockets to deRaadt's grasp. And the connections go both ways too: deRaadt has a blatant chip on his shoulder regarding Intel. Ultimately, it hasn't been enough for deRaadt to level unsubstantiated libels at Intel, or to elicit spurious security fears about its solidly tested products. He's added an extra layer of hypocrisy on top by attacking Intel for being opaque and complaining about made-up fatal flaws in their Core 2 system. I would go as far as to posit that it is in fact deRaadt's system for running the OpenBSD project which has a fatal flaw. This escapade proves that deRaadt -- and by extension the OpenBSD project -- is simply too vulnerable to external influence from corporations with a vested interest and lots of lucre. Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.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] Remote hole in OpenBSD 4.1
Gadi Evron wrote: I formerly had a great deal of respect, bordering on admiration, for Theo deRaadt's refusals to compromise his open source principles, even in the face of stiff opposition. Although he has occasionally gone over-the-top, recommended some frankly very dubious changes to OpenBSD, and is regularly arrogant (which is even more annoying because he's so often right!), he's always remained consistent in his devotion to the cause of GNU/Free Software. Notice formerly: my confidence in deRaadt has been soundly shaken by his latest round of unfounded aspersions cast against Intel's Core 2 line of CPUs. Instead of getting the facts with careful analysis and study, deRaadt has jumped the gun by trying to preempt proper research with posts to the openbsd-misc mailing list. This in itself wouldn't be so bad, but his only proper citation is a 404 page, and his only other source is an old summary of unverified errata from a hobbyist website. The lack of fact-checking and complete absence of any credible sources for his allegations is suspicious in itself, but he compounds it into a complete boner by making an equally unsupported claim that the supposed (in fact non-existent) CPU problems are security flaws: As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are. Without real references to backup his exaggerated concerns, deRaadt's post crosses the line into outright libel and scare-mongering. It's obvious when you know what to look for: the subtle use of neurolinguistic priming in emotive leading phrases such as some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us, Open source operating systems are largely left in the cold, hiding in this list, and so forth. This does not lead me to share Theo's purported fears; instead it leads me to believe that he's trying to unduly influence Intel's reputation with lies. I have an idea of why. It's the same reason deRaadt feels comfortable in saying that he'd bet a lot of money on Intel's Core 2 processors having multiple (not one, but several) security flaws originating from these errata. Namely, one of Intel's largest competitors has supplied the OpenBSD project with a substantial amount of monetary support since 2004, presumably because they can't compete even in the open source market without propping it up with a flow of money. They cannot maintain their position on the processor front, so they're resorting to buying out open source software developers. It's regrettably cheap to do so, even if they have deRaadt's prestige, because their business models stifle income and so a monolith such as AMD can trivially tempt them with greater incentives. In fact deRaadt is an easier target for donations because he makes it clear that he has no business model for OpenBSD. Intel, by contrast, have no discernable incentive to deceive or play down security flaws in their products; the consecutive f00f and FDIV bugs of the past have taught Intel that their best course of action is to face up to their errors and offer speedy fixes. DeRaadt's claim that Intel must be come [sic] more transparent is most unfounded, especially when one considers who stands to benefit from this anti-Intel arrangement; the connections between the AMD-ATI leviathan and deRaadt-driven projects are not hard to find. AMD make a point of emphasising OpenBSD's place in the AMD64 ecosystem, and, as already mentioned, lends its deep pockets to deRaadt's grasp. And the connections go both ways too: deRaadt has a blatant chip on his shoulder regarding Intel. Ultimately, it hasn't been enough for deRaadt to level unsubstantiated libels at Intel, or to elicit spurious security fears about its solidly tested products. He's added an extra layer of hypocrisy on top by attacking Intel for being opaque and complaining about made-up fatal flaws in their Core 2 system. I would go as far as to posit that it is in fact deRaadt's system for running the OpenBSD project which has a fatal flaw. This escapade proves that deRaadt -- and by extension the OpenBSD project -- is simply too vulnerable to external influence from corporations with a vested interest and lots of lucre. Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.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/ Nice try, but (Wrong list). Too little to late. firstly you employ the trick of accuse them first when you get to neurolinguistic priming your text is full of it.
Re: [Full-disclosure] Remote hole in OpenBSD 4.1
There's something about this that makes my blood boil. I'm not sure what it is, but I don't think it's the post by this particular individual, but rather the behaviour and actions of Theo de Raadt in the past. First off, the contents of this email do not shock me. In fact, I would say this would be the kind of hypocrisy I would expect from Theo. He is arrogant, loud and generally outspoken about other peoples' behaviour, but when it comes to how he behaves himself on mailing lists, in public or otherwise he clearly holds a set of double standards. While he often calls FreeBSD and Linux developers sellouts because they sign NDAs to create drivers to support new hardware, he turns around and secretly does the same thing with AMD, only in a worse fashion -- spreading FUD against AMD's main competitor, Intel. What's next, AMD is going to pay him to rail against nVidia too? What I find most appalling about all of this is when I read Kuro5hin this morning I saw this post come up: http://www.kuro5hin.org/story/2007/8/2/15233/84896 And when I checked back later this afternoon, Theo had actually replied, heatedly. A few things in his response also don't lend him any credibility. First, he makes thinly veiled legal threats and outrageous demands that the article be taken down and that an apology be made. I guess Theo's love and belief in free speech (and flaming FreeBSD and Linux developers) is not something other people are allowed to have -- you can't credit Theo (Caesar can do no wrong, after all). Second he admits that there is a relationship between him and AMD, and that AMD has provided the project support in the past. In fact, he seems to try to downplay it, and make it look like the support is token at best. I find this very hard to believe, since OpenBSD has often been placed before other BSDs in AMD's AMD64 ecosystem. Finally, his general attitude throughout the email (and grammatical errors) suggests that he recognizes he is doing something wrong, and is angry that someone is calling him out on it. If Theo truly felt that he was working legitimately and wasn't doing anything sketchy behind the scenes in his dealings with AMD and other major vendors, perhaps the fact that he's being scrutinized should be welcome, and allow him to show the world how clean his conscience is. The fact that he literally freaked out and went on a rampage suggests to me, however, that his conscience is not clear and that he is afraid that somebody is on the trail of his questionable doings. Best regards, Michael. ___ 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] Remote hole in OpenBSD 4.1
Michael Smythe wrote: snip What I find most appalling about all of this is when I read Kuro5hin this morning I saw this post come up: http://www.kuro5hin.org/story/2007/8/2/15233/84896 And when I checked back later this afternoon, Theo had actually replied, heatedly. A few things in his response also don't lend him any credibility. snip pot, kettle, black. I read the kuro5hin URL and I didn't feel the heatedly part. Caveats: - Yes, TdR can be a bit over the top sometimes. - I know nothing about OpenBSD's relationship with AMD or Intel. I only have TdR's comments on the Kuro5hin page to go on. - I could care less about OpenBSD's relationship with AMD or Intel. However, I /*do*/ have an unflattering opinion of Intel. IMHO, they're worse than M$ when it comes to initmidating first-line customers (read OEMs) and abusing their position in the market. Google Intel + anti-trust for starters. I don't see that their technology is any better than AMD's and, in most cases, it's playing catch-up. Goes way back to the 808x days when cycle-for-cycle, the Z80 beat the pants off the 8080. Then there's also the Itanic debacle with HP. It's /*still*/ IMHO not competitive with the DEC AXP platform ca 1990 and the HPPA architecture. So, my take on all this is Give me a break! Intel is a bully and a technology second-rate. But they do have deep pockets and they /*are*/ willing to browbeat their best customers. Mt 0.02$CURRENCY. /g ___ 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] Chacha search engine vulnerablity
There is an XSS vulnerability in the Chacha search engine - possible XSRF as
well.
http://search.chacha.com/search/query?query='
http://search.chacha.com/search/query?query=%27
scriptalert('xss')/script
mode=webwsid=6661f6c2-b53a-666a-666e-dd666e666dda
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
