Re: [Full-disclosure] plz suggest security for DLL functions
thanks a lot friends. i really got some innovative ideas from all of you. regards, gaurav On 7/2/05, John LaCour <[EMAIL PROTECTED]> wrote: > Another suggestion - also not bullet proof - but largely effective: > > 1) Write a kernel mode driver that hooks the Win32 APIs to load DLLs > and filter any calls by programs other than your own. > > 2) Ensure your driver protects itself. There's a long list of things > to do including: > - protect the registry key / hive > - protect the driver file > - protect access to physical memory > - etc. etc. > > 3) Ensure that attacks to undo API hooks are prevented. > See http://www.security.org.sg/code/sdtrestore.html as an example of > these attacks (which can be used for evil or good in the case of > undoing rootkit hooks). > > As others have mentioned, the above made be significantly more > expensive than the good EULA and lawyers route. > > -John > > On 6/30/05, Gaurav Kumar <[EMAIL PROTECTED]> wrote: > > friends, > > > > We are developing a software that makes use of a COM DLL. The whole > > logic lies in the dll. The User Interface is in VC++. DLL exposes > > functions, application calls it and displays result. Now, we found > > that anybody can copy the DLL, register it and make use of those > > functions. > > > > Please guide us in making those functions secret or encrypted so that > > others cannt use our functions. > > > > thanks and regards, > > gaurav > > ___ > > 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] Re: [VulnWatch] Microsoft Windows NTFS Information Disclosure
James Tucker wrote: cacls *.chk /G administrator:F in shared environments where for some reason your users have access to their drives. ...which doesn't solve a thing. That workaround won't impact anything. It will simply mark existing CHK files with that ACL. Any new ones that are created in the future will not have it. Generally, by the time you're executing that command, damage is already done. In any case, .CHK files aren't any part of the exploit. To my knowledge, NTFS generates no such files (as file operations are journaled, and therefore, reversible if they aren't completed). Something is awry in the shutdown/recovery process of XP that causes it to append re-used and uninitialized disk or cache blocks to files open for write at shutdown. These files appear as *normal* files. I've seen this type of "garbage" (some of it in fact, very sensitive) in logs for IIS, for instance. -- "Education is a weapon whose effects depend on who holds it in his hands and at whom it is aimed." -- Joseph Stalin smime.p7s Description: S/MIME Cryptographic 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] Re: [VulnWatch] Microsoft Windows NTFS Information Disclosure
cacls *.chk /G administrator:F in shared environments where for some reason your users have access to their drives. On 6/30/05, Matthew Murphy <[EMAIL PROTECTED]> wrote: > Melvin Klassen wrote: > > >[EMAIL PROTECTED] (Matthew Murphy) at Jun 30, 2005 12:01:59 PM wrote: > > > > > > > >>However, an apparent error in the NTFS driver's code causes the file > >>system to incorrectly assign disk blocks to files before they have been > >>initialized. Following a recovery from a system shutdown, uninitialized > >>data may be visible in files from previously allocated disk blocks. > >> > >> > > > >As far as I know, _every_ major Operating System has the same vulnerability. > > > >I do _NOT_ know of any Operating System that "zero's" each newly-allocated > >block/sector/track/cylinder of disk-space when allocating a "new" file, > >whether on disk, or on magnetic tape, or on removable media. > > > > IBM AIX?No. > > IBM z/VM? No. > > IBM z/OS? No. > > IBM OS/2? No. > > HP/UX? No. > > Linux? No. > > MS DOS? No. > > MS Windows? No. > > > > > I wrote a more detailed reply to Melvin off-list. This response misses > the point of the issue... which is not the fact that uninitialized data > exists on disk (a known fact exploited by everything from "Delete undo" > tools to forensic software), but that the NTFS accounting code treats > said data as a valid portion of the file's content, thus making it > readable to users without privileged access to the system. > > VulnWatch Mod Note: Moved to VulnDiscuss, as I feel this to be the more > sensible forum of discussion. You may want to move the original > response there as well, to avoid confusion. > > > ___ > 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] plz suggest security for DLL functions
Another suggestion - also not bullet proof - but largely effective: 1) Write a kernel mode driver that hooks the Win32 APIs to load DLLs and filter any calls by programs other than your own. 2) Ensure your driver protects itself. There's a long list of things to do including: - protect the registry key / hive - protect the driver file - protect access to physical memory - etc. etc. 3) Ensure that attacks to undo API hooks are prevented. See http://www.security.org.sg/code/sdtrestore.html as an example of these attacks (which can be used for evil or good in the case of undoing rootkit hooks). As others have mentioned, the above made be significantly more expensive than the good EULA and lawyers route. -John On 6/30/05, Gaurav Kumar <[EMAIL PROTECTED]> wrote: > friends, > > We are developing a software that makes use of a COM DLL. The whole > logic lies in the dll. The User Interface is in VC++. DLL exposes > functions, application calls it and displays result. Now, we found > that anybody can copy the DLL, register it and make use of those > functions. > > Please guide us in making those functions secret or encrypted so that > others cannt use our functions. > > thanks and regards, > gaurav > ___ > 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] Publishing exploit code - what is it good for
On Thu, Jun 30, 2005 at 10:36:57AM -0700, Erick Mechler wrote: > :: Blackhats may get along with only a handful of exploits, if they're > :: willing to try to find targets to match their collection, but a > :: pentester should have the collection to match the target. > :: > :: This is doubly true if we're not talking about a dedicated pentester, > :: but about a sysadmin with a networking/security background who likes to > :: verify that the patches did, indeed, work. > > To that I say let the people producing the patches deliver the exploit code > as a POC that the patches did, indeed, work. Releasing exploit code before > the patch is released helps nobody except the blackhats. > > :: Also, exploits will be distributed, publicly or otherwise - doing it in > :: the open means we know what happens when. > > You should, as an admin, assume that once a vulnerability is released, the > exploit has been too, whether you see it attached to the vuln announcement > or not. > > Cheers - Erick Dear Erick, Those are two very valid points. I agree with you on the first, in general at least (if there's evidence that the vulnerability is exploited in the wild, and the vendor has made it clear through action or inaction that no patch is forthcoming, a publicly posted exploit can serve as a much-needed cattle prod - but that's a relatively uncommon situation). However, I wasn't talking about this, and I assume the OP wasn't, either; this is not an argument not to release exploit code at all. The second is true; however, it's also true that when there's a skiddie-friendly exploit out there, you can expect to see a lot more attacks. Pretty soon. And as pointed out further in the same thread, exploits function as a much-needed cattle prod for lazy admins too. And yes, I've needed the prodding a few times, myself. Joachim ___ 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] UnixWare 7.1.4 : Mozilla updated to 1.7.8 fixes security issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 __ SCO Security Advisory Subject:UnixWare 7.1.4 : Mozilla updated to 1.7.8 fixes security issues Advisory number:SCOSA-2005.29 Issue date: 2005 July 01 Cross reference:sr893376 fz531626 erg712820 sr892164 fz530485 erg712734 sr891008 fz529877 erg712655 CAN-2005-1476 CAN-2005-1477 CAN-2005-1531 CAN-2005-1532 CAN-2005-0989 CAN-2005-1153 CAN-2005-1154 CAN-2005-1155 CAN-2005-1156 CAN-2005-1157 CAN-2005-1159 CAN-2005-1160 __ 1. Problem Description Fixed in Mozilla 1.7.8 MFSA 2005-44 Privilege escalation via non-DOM property overrides MFSA 2005-43 "Wrapped" javascript urls bypass security checks MFSA 2005-42 Code execution via javascript: IconURL The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2005-1476, CAN-2005-1477, CAN-2005-1531, and CAN-2005-1532 to these issues. Fixed in Mozilla 1.7.7 MFSA 2005-33 Javascript "lambda" replace exposes memory contents MFSA 2005-35 popup uses wrong privilege context MFSA 2005-36 Cross-site scripting through global scope pollution MFSA 2005-37 Code execution through javascript: favicons MFSA 2005-38 Search plugin cross-site scripting MFSA 2005-40 Missing Install object instance checks MFSA 2005-41 Privilege escalation via DOM property overrides The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the following names for these issues: CAN-2005-0989, CAN-2005-1153, CAN-2005-1154, CAN-2005-1155, CAN-2005-1156, CAN-2005-1157, CAN-2005-1159, CAN-2005-1160. 2. Vulnerable Supported Versions System Binaries -- UnixWare 7.1.4 distribution 3. Solution The proper solution is to install the latest packages. 4. UnixWare 7.1.4 4.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.29 4.2 Verification MD5 (mozilla.image) = 71827da87c708125b3c9fa317755e7a7 md5 is available for download from ftp://ftp.sco.com/pub/security/tools 4.3 Installing Fixed Binaries Upgrade the affected binaries with the following sequence: Download mozilla.image.pkg to the /var/spool/pkg directory # pkgadd -d /var/spool/pkg/mozilla.image.pkg 5. References Specific references for this advisory: http://www.mozilla.org/projects/security/known-vulnerabilities.html#Mozilla http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1476 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1477 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1531 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1532 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0989 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1153 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1154 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1155 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1156 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1157 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1159 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1160 SCO security resources: http://www.sco.com/support/security/index.html SCO security advisories via email http://www.sco.com/support/forums/security.html This security fix closes SCO incidents sr893376 fz531626 erg712820 sr892164 fz530485 erg712734 sr891008 fz529877 erg712655. 6. Disclaimer SCO is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of SCO products. __ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (SCO/SYSV) iD8DBQFCxbiXaqoBO7ipriERAji3AJ9rBN/wUwwXcBVYemy19pyw+oeusgCglSq/ yCBgL6LwkzfRzdO4js9ZzX4= =IhiA -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] plz suggest security for DLL functions
On 01/07/05 10:43 +0530, Gaurav Kumar wrote: > friends, > > We are developing a software that makes use of a COM DLL. The whole > logic lies in the dll. The User Interface is in VC++. DLL exposes > functions, application calls it and displays result. Now, we found > that anybody can copy the DLL, register it and make use of those > functions. > > Please guide us in making those functions secret or encrypted so that > others cannt use our functions. Distribute a statically linked binary? Devdas Bhagat ___ 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] plz suggest security for DLL functions
Who said anything about Windows? The concept of a remote procedure call is much older than Microsoft, and Sun had RPC to support NFS while Windows was still thinking about how to implement TCP Quite right .. I was just in the original mindset of the question. I also failed to mention that it need not be RPC that's exposed to actually make it work .. it could (should) be wrapped via most any tunnel. From a practical standpoint, if you're going to "host" the SecretSauce.DLL file, you might as well just offer the whole thing as a hosted application. You're still probably best off with a good EULA and legions of lawyers. ~Mike. ___ 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] plz suggest security for DLL functions
On Fri, 01 Jul 2005 14:37:18 EDT, Tim said: > > Give them a DLL that just tosses an RPC call to a secured server that you > > manage. > > And how would your server differentiate between a "good" RPC call and a > "bad" one? Well - you *do* have some idea of what sort of abuse you're trying to stop, right? If they're not allowed to call it more than X times/hour, rate limit your RPC server. Or apply whatever other checks you want to. At least you (hopefully) don't have to worry about the user running your server under a debugging tool to reverse engineer it. :) pgpMgG3DMxszd.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] plz suggest security for DLL functions
On Fri, 01 Jul 2005 15:14:06 EDT, Michael Holstein said: > >Give them a DLL that just tosses an RPC call to a secured server that you > >manage. > > Rght. "Secure" something by putting it on a Windows machine with RPC > exposed to the Internet. Who said anything about Windows? The concept of a remote procedure call is much older than Microsoft, and Sun had RPC to support NFS while Windows was still thinking about how to implement TCP pgpwjlaieRAzP.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] plz suggest security for DLL functions
Please guide us in making those functions secret or encrypted so that others cannt use our functions. Nope. You can make it marginally more difficult (encrypted) but you can't "prevent" it entirely .. and the harder you try to make it, the more fun you make it for crackers to reverse-engineer. About the best you could do to hide the "super secret sauce" (lol .. Vladis) is put it on a secure token (eg: SmartCard) and call it from there. While not foolproof, hardware is [generally] more difficult to hack. Cheers, Michael Holstein CISSP GCIA Cleveland State University ___ 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] plz suggest security for DLL functions
Give them a DLL that just tosses an RPC call to a secured server that you manage. Rght. "Secure" something by putting it on a Windows machine with RPC exposed to the Internet. ~Mike. ___ 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] plz suggest security for DLL functions
> Give them a DLL that just tosses an RPC call to a secured server that you > manage. And how would your server differentiate between a "good" RPC call and a "bad" one? > Another, even better, idea is to give them a click-through EULA that contains > a line of the form "misusing or reverse-engineerng our usage of jalepenos will > result in a $MOBY surcharge and/or other legal action" Yes, this is probably all you'll be able to do. (Besides code obfuscation that doesn't make your code significantly harder to "steal".) It is trivial for any attacker to throw a brick through my window and steal all of my furniture while I am not home. Why don't they do it on a daily basis? The risk and consequences of getting caught vs. the rewards of fencing my crappy furniture. tim ___ 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] plz suggest security for DLL functions
On Fri, 01 Jul 2005 15:26:06 +0530, Gaurav Kumar said: > if it would have been so simpler, i wouldnt have asked it here, > the application design doesnt allow us to use the conventioal > loadlibray method. we need to export functions also and at the same > time protect from misuse. Give them a DLL that just tosses an RPC call to a secured server that you manage. In general, if it's (even potentially) in their address space, they can misuse it. So the only real solution making sure that your Secret Sauce code is on some other system where they can't find out it's just Miracle Whip and a shot of jalepenos Another, even better, idea is to give them a click-through EULA that contains a line of the form "misusing or reverse-engineerng our usage of jalepenos will result in a $MOBY surcharge and/or other legal action" pgpZjonfJksqh.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] plz suggest security for DLL functions
> Try signing the hash of all your function arguments with a private key > and then in the function calculating the hash and verifying the > signature... > The public key could be extracted from the dll or the dll could be > reverse enginereed to remove the checks but this is still a good > method to prevent totally clueless people from using your dll. Make it as complicated as you want, with as much crypto as you like, and a skilled attacker will just find those key branch instructions and alter them to jump where necessary. You can obfuscate it, but you can't make it secure. You'll just have to live with that fact. You might be able to track the illegitimate use of your DLL with watermarks, but you won't be able to prevent it if someone really wants to use it that badly. tim ___ 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] plz suggest security for DLL functions
Hi. Try signing the hash of all your function arguments with a private key and then in the function calculating the hash and verifying the signature... The public key could be extracted from the dll or the dll could be reverse enginereed to remove the checks but this is still a good method to prevent totally clueless people from using your dll. btw MS does something like this :) On 7/1/05, Gaurav Kumar <[EMAIL PROTECTED]> wrote: > friends, > > We are developing a software that makes use of a COM DLL. The whole > logic lies in the dll. The User Interface is in VC++. DLL exposes > functions, application calls it and displays result. Now, we found > that anybody can copy the DLL, register it and make use of those > functions. > > Please guide us in making those functions secret or encrypted so that > others cannt use our functions. > > thanks and regards, > gaurav > ___ > 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] Zone-H Comics
Hello, you might be interested to Zone-H comics, the first-ever hacker comics. For free. You can found it @ http://www.zone-h.org/comics Bye -- Gerardo -Astharot- Di Giacomo Zone-H Admin ___ 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] Re: Published exploit codes foo foo foo
Original Message >From: J. Oquendo >Message-Id: [EMAIL PROTECTED] > Would be interesting to see where the > majority of sloppy coders, whose projects have been exploited, come from. Seattle. HTH. Wonderful though it would be if it was all someone else's fault, it's wishful thinking. We've *been* the software business for the past 30 years and it's wishful thinking to hope that all the problems are the fault of the most recent newcomers. "The crisis in software engineering" has been a recognized and ongoing problem since the late 60s. (And before that, it was still "ongoing", just not "recognized"). cheers, DaveK -- Can't think of a witty .sigline today ___ 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] [ZH2005-14SA] Phishing problems on MSN
[ZH2005-14SA] Phishing problems on MSN Date: July 1th 2005 Author:Giovanni Delvecchio email: [EMAIL PROTECTED] Overview === Multiple phishing problems exist on support.msn.com, permitting to a possible attacker to conduct phishing attack against a user. Details = 1)Input passed to the "ru" parameter in "pplogin.aspx" isn't properly sanitised before being returned to the user Example: http://support.msn.com/pplogin.aspx?ru=http://www.evil- site.com">www.msn.com/ or http://support.msn.com/pplogin.aspx?ru=%68%74%74%70%3A%2F%2F%77%77%77% 2E%65%76%69%6C%2D%73%69%74%65%2E%63%6F%6D%22%3E%77%77%77%2E%6D%73%6E% 2E%63%6F%6D/ The problem has been fixed today. Here is possible see a screen shot: http://www.zone-h.org/files/49/msn1.jpg 2)Input passed to the 'mspplogin' parameter isn't properly sanitised, and by using specialy crafted URL an attacker can cause the user to be redirected to an arbitrary URL for the passport authentication. Example: http://support.msn.com/pplogin.aspx?msppchlg=1&mspplogin=http://www.evil-site.com/login.srf%3F This problem at the moment has not been fixed. Reference === http://www.zone-h.org/advisories/read/id=7764 _ Ricerche online più semplici e veloci con MSN Toolbar! http://toolbar.msn.it/ ___ 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] plz suggest security for DLL functions
hi , maybe by inserting some piece of code in the begining of all of your dll functions that check the caller before doing its job , and so if this is not your original app make sure the dll return without doing something. regards, stephane. - Original Message - From: "Gaurav Kumar" <[EMAIL PROTECTED]> To: "Abhisek Datta" <[EMAIL PROTECTED]> Cc: Sent: Friday, July 01, 2005 11:56 AM Subject: Re: [Full-disclosure] plz suggest security for DLL functions if it would have been so simpler, i wouldnt have asked it here, the application design doesnt allow us to use the conventioal loadlibray method. we need to export functions also and at the same time protect from misuse. regards, gaurav On 7/1/05, Abhisek Datta <[EMAIL PROTECTED]> wrote: > Please guide us in making those functions secret or encrypted so that > others cannt use our functions. Using Windows DLL APIs, normally only those functions exported by a DLL can be called by a process that maps the DLL in its address space. The simplest solution is not to export the functions which u do not want to be used by other programs using conventional LoadLibrary and GetProcAddress.. in that case u need some clever hack for ur own application that maps the entire DLL in its address space implements offset based calculation to find the address of ur unexported functions in the DLL and return to it, though i havent implemented these concept but i think it is quite possible and can do it if required. as far as encryption is concerned, u can encrypt ur DLL as per ur wish and decrypt it from ur userland application before memory mapping. In any case, the phrase "others cant use the function" is not realy feasible as far as i am concerned. btw. Gaurav, I suggest better do ur homework using google or something similar before asking these questions cause it sounds clueless.. Regards, - Abhisek -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/35 - Release Date: 30/06/2005 ___ 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] RE: Publishing exploit code - what is it good for
Hi Aviram, I use this type of code to ensure that when patches are applied, it does not "break" any part of the OS and or application which has already been patched. Also I don't take anyone's word that a system has been patched or a security hole has been fixed without testing and re-certifying the application or the OS. Without the exploit code I would not be able to verify any of this and could very well leave my systems wide open. In a private sector company this code should be used in the same manner, to ensure compliance with SOX. To leave systems untested would be hanging your company out to dry. David Morales [EMAIL PROTECTED] 703-696-4022 -Original Message- From: Aviram Jenik [mailto:[EMAIL PROTECTED] Sent: Thursday, June 30, 2005 8:14 AM To: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com Subject: Publishing exploit code - what is it good for Hi, I recently had a discussion about the concept of full disclosure with one of the top security analysts in a well-known analyst firm. Their claim was that companies that release exploit code (like us, but this is also relevant for bugtraq, full disclosure, and several security research firms) put users at risks while those at risk gain nothing from the release of the exploit. I tried the regular 'full disclosure advocacy' bit, but the analyst remained reluctant. Their claim was that based on their own work experience, a security administrator does not have a need for the exploit code itself, and the vendor information is enough. The analyst was willing to reconsider their position if an end-user came forward and talked to them about their own benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Help me out here. Full disclosure is important for me, as I'm sure it is for most of the people on these two lists. If you're an end-user organization and are willing to talk to this analyst and explain your view (pro-FD, I hope), drop me a note and I'll put you in direct contact. Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. -- Aviram Jenik Beyond Security http://www.BeyondSecurity.com http://www.SecuriTeam.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 736-1] New spamassassin packages fix potential DOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory 736-1 [EMAIL PROTECTED] http://www.debian.org/security/Michael Stone July 01, 2005 http://www.debian.org/security/faq - Package: spamassassin Vulnerability : mail header parsing error Problem type : remote DOS Debian-specific: no CVE Id(s) : CAN-2005-1266 Debian Bug : 314447 A vulnerability was recently found in the way that SpamAssassin parses certain email headers. This vulnerability could cause SpamAssassin to consume a large number of CPU cycles when processing messages containing these headers, leading to a potential denial of service (DOS) attack. The version of SpamAssassin in the old stable distribution (woody) is not vulnerable. For the stable distribution (sarge), this problem has been fixed in version 3.0.3-2. Note that packages are not yet ready for certain architectures; these will be released as they become available. For the unstable distribution (sid), this problem has been fixed in version 3.0.4-1. We recommend that you upgrade your sarge or sid spamassassin package. Upgrade instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian 3.1 (sarge) - -- Source archives: http://security.debian.org/pool/updates/main/s/spamassassin/spamassassin_3.0.3-2.diff.gz Size/MD5 checksum:44610 b1b383fc4f9dc0792ecd954fa99aaa56 http://security.debian.org/pool/updates/main/s/spamassassin/spamassassin_3.0.3.orig.tar.gz Size/MD5 checksum: 999558 ca96f23cd1eb7d663ab55db98ef8090c http://security.debian.org/pool/updates/main/s/spamassassin/spamassassin_3.0.3-2.dsc Size/MD5 checksum: 776 4f3092c679992ad322598f4195f4800c Architecture independent packages: http://security.debian.org/pool/updates/main/s/spamassassin/spamassassin_3.0.3-2_all.deb Size/MD5 checksum: 768948 b2d7f49923aa67d8a016e5a3b3545249 alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_alpha.deb Size/MD5 checksum:61552 84fcd819583c747545fda079a074d987 i386 architecture (Intel ia32) http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_i386.deb Size/MD5 checksum:58438 18138ce49c9d249fb5d93487e60481a2 ia64 architecture (Intel ia64) http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_ia64.deb Size/MD5 checksum:65020 65e214d1922317d511e23c32f7e19ff6 m68k architecture (Motorola Mc680x0) http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_m68k.deb Size/MD5 checksum:57536 b13aad3cb78a148e8838ddfdb301dbd5 mips architecture (MIPS (Big Endian)) http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_mips.deb Size/MD5 checksum:60228 8578263361ff0e95ed0bddc2493d620e mipsel architecture (MIPS (Little Endian)) http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_mipsel.deb Size/MD5 checksum:60202 2338edb2f9679396005d490232147b7b powerpc architecture (PowerPC) http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_powerpc.deb Size/MD5 checksum:60578 e547e452fc5e7ed28b04065af1b677a0 s390 architecture (IBM S/390) http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_s390.deb Size/MD5 checksum:59436 32ab8a7fef23ac35912ae51cc22aad29 sparc architecture (Sun SPARC/UltraSPARC) http://security.debian.org/pool/updates/main/s/spamassassin/spamc_3.0.3-2_sparc.deb Size/MD5 checksum:58370 8791b8226b25a0bc5381f39257ecd547 - --- For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org Package info: `apt-cache show ' and http://packages.debian.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQCVAwUBQsSl5w0hVr09l8FJAQJckQP+It+rZFa4xKdZUM5f3OWBXEOUdxbsZ3vB Q/2V/PHyNOP2xXT81M+ZUXk+Tggi4TuBFaxXfg/gHOuYE7vcfBfT/hpxjvgDgTXI PDUQSpdRjmPMgQq84eUryJzQNwwXv5iVFjeKDrDTDd3qnBja707XZTUuotYGgUp2 KdvwCAkNzrE= =TN0J -END PGP SIGNATURE- ___ Full-Disclosure
[Full-disclosure] RE: Publishing exploit code - what is it good for
I for one am glad to see PoC code. Too often vendors are very vague with their patchsets (Oracle basically says to install a huge tarball to fix 'critical' vulnerabilities without listing exactly what it fixes and the recent Backup Exec vulnerability had a later patch version available for a different unrelated problem than the published advisory for the agent password overflow - you had to read three different advisories to find out if the later patchset had the fix - it did, even then it was a crap shoot). Given the lack of disclosure from the vendors, I like to have PoC code available to test if the patch really was applied correctly (and was the correct one). Don't forget the instances when either a patch silently fails, or if you are a security admin, don't trust that the admins really patched all of their machines. I would forgo most PoC codes if vendors would *exactly* explain what was in their patchsets (and provided a way to test for the existence of easily) and what they addressed without these matrix's of different versions of their product cross-referenced to a simple 'critical' reference. Even as vague as MS announcements are, they are still one of the better disclosing vendors when it comes to their announcements. Then again, I like to learn from the PoC code to further my knowledge as how the inner workings of programs work and how much of a poor job someone did while coding it. ___ 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] Re: Publishing exploit code - what is it good for
Interesting, becuase this just hit me the other day. Wearing my sysadmin hat, I woke up one morning to find that the NetBSD package converters/xlreader had a vulnerability. Nobody seemed to have a patch for it, but looking at it, even with my rather limited level of C coding skill, I reckoned I could fix it. (Standard buffer overflow: replace sprintf with snprintf kinda thing.) So I did. Or at least, I think I did. I can't get my hands on a working exploit, so I don't feel truly comfortable that I did indeed fix the problem. Maybe to someone more familiar with C it would be proved fixed by inspection, but I don't feel that comfortable with it myself. I didn't really used to think that exploits were so useful until this. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org Make up enjoying your city life...produced by BIC CAMERA ___ 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] plz suggest security for DLL functions
if it would have been so simpler, i wouldnt have asked it here, the application design doesnt allow us to use the conventioal loadlibray method. we need to export functions also and at the same time protect from misuse. regards, gaurav On 7/1/05, Abhisek Datta <[EMAIL PROTECTED]> wrote: > > Please guide us in making those functions secret or encrypted so that > > others cannt use our functions. > > Using Windows DLL APIs, normally only those functions exported by a > DLL can be called by a process that maps the DLL in its address space. > The simplest solution is not to export the functions which u do not > want to be used by other programs using conventional LoadLibrary and > GetProcAddress.. in that case u need some clever hack for ur own > application that maps the entire DLL in its address space implements > offset based calculation to find the address of ur unexported > functions in the DLL and return to it, though i havent implemented > these concept but i think it is quite possible and can do it if > required. > > as far as encryption is concerned, u can encrypt ur DLL as per ur wish > and decrypt it from ur userland application before memory mapping. > > In any case, the phrase "others cant use the function" is not realy > feasible as far as i am concerned. > > btw. Gaurav, I suggest better do ur homework using google or something > similar before asking these questions cause it sounds clueless.. > > Regards, > - Abhisek > > On 7/1/05, Gaurav Kumar <[EMAIL PROTECTED]> wrote: > > friends, > > > > We are developing a software that makes use of a COM DLL. The whole > > logic lies in the dll. The User Interface is in VC++. DLL exposes > > functions, application calls it and displays result. Now, we found > > that anybody can copy the DLL, register it and make use of those > > functions. > > > > Please guide us in making those functions secret or encrypted so that > > others cannt use our functions. > > > > thanks and regards, > > gaurav > > ___ > > 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] plz suggest security for DLL functions
> Please guide us in making those functions secret or encrypted so that > others cannt use our functions. Using Windows DLL APIs, normally only those functions exported by a DLL can be called by a process that maps the DLL in its address space. The simplest solution is not to export the functions which u do not want to be used by other programs using conventional LoadLibrary and GetProcAddress.. in that case u need some clever hack for ur own application that maps the entire DLL in its address space implements offset based calculation to find the address of ur unexported functions in the DLL and return to it, though i havent implemented these concept but i think it is quite possible and can do it if required. as far as encryption is concerned, u can encrypt ur DLL as per ur wish and decrypt it from ur userland application before memory mapping. In any case, the phrase "others cant use the function" is not realy feasible as far as i am concerned. btw. Gaurav, I suggest better do ur homework using google or something similar before asking these questions cause it sounds clueless.. Regards, - Abhisek On 7/1/05, Gaurav Kumar <[EMAIL PROTECTED]> wrote: > friends, > > We are developing a software that makes use of a COM DLL. The whole > logic lies in the dll. The User Interface is in VC++. DLL exposes > functions, application calls it and displays result. Now, we found > that anybody can copy the DLL, register it and make use of those > functions. > > Please guide us in making those functions secret or encrypted so that > others cannt use our functions. > > thanks and regards, > gaurav > ___ > 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/
