What if a license has a clause that requires an insecure or problematic setting/configuration/behavior? Someone did a parody licence called the " Insecure License" but I wouldn't put it past sometime to have done this for real. What about audit clauses (e.g. can I audit the NSA usage of my product) and other forms of information disclosure?
On Thu, Nov 9, 2023 at 11:46 AM Przemyslaw Roguski <[email protected]> wrote: > Hi Jon, Thank you for accepting different opinions and I'm really happy > that we have this discussion here. To be honest I never consider licensing > issues as a potential problem that could be considered as a software > weakness. But it seems > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > This message originates outside of MITRE. If you feel this is suspicious, > please report it via "Report Suspicious Email" button in Outlook. > > ZjQcmQRYFpfptBannerEnd > Hi Jon, > > Thank you for accepting different opinions and I'm really happy that we > have this discussion here. > To be honest I never consider licensing issues as a potential problem that > could be considered as a software weakness. > But it seems that such a clarification is required. > Let me repeat what I said before, regardless of the declared licence > (valid or not) still you can be impacted if you run a malicious > software/code. > Like in Arthur's example. > > Thank you Arthur for your great examples! > > Jon, let me try to provide one more clarification. If your license > management software will accept invalid licence and recognize it as a > valid one, then yes, it's a licence related weakness, but it's a weakness > in your software, not a problem with the wrong license itself that was > provided. Depending on the root cause in such a case it could be "CWE-184: > Incomplete List of Disallowed Inputs" weakness related to the license > management software. You can blame the invalid license, but in fact the > root cause and the weakness is in the license management software. > > Like it was said a few times, licence by itself, regardless if valid or > not, cannot lead to vulnerability, hence cannot be classified as a weakness > as well. > Invalid licence can lead to legal problems, but this is a different story. > > I hope it helps. > > Best regards, > Przemek > > Przemyslaw Roguski > > Security Architect, Product Security > > Red Hat Poland <https://www.redhat.com/> > > [email protected] IM: rogue > > <https://red.ht/sig> > > On Thu, Nov 9, 2023 at 6:49 PM Hood, Jonathan W CTR USARMY DEVCOM AVMC > (USA) <[email protected]> wrote: > >> I understand the position better with this analogy; thank you. >> >> >> >> I do believe that it is not a comparable analogy. Raising energy prices >> are not a property of the software. A software license is a property of the >> software, so the argument you make here is based off of an initial >> assertion that seems incorrect. Just because the fix for the weakness is >> voluntary doesn’t mean it’s not a weakness (IE: voluntarily stop using >> untrusted components, CWE-1357), though license enforcement may not be >> voluntary in all cases. >> >> >> >> “It doesn’t do anything to stop the execution of that software on any >> system not under your direct control where it’s already running” – I’m >> arguing that it does. When you incorporate software in violation of the >> license, you expose your product to injunction or restraint which >> absolutely can apply to the executing software directly under your control. >> For example, if the Home Depot website used software without licensing it, >> the software may have a license enforcement mechanism (and would have the >> legal authority to) shut off the software once the license becomes >> unverified, or Home Depot may receive an injunction to stop using the >> unlicensed software. Either of these scenarios would directly affect the >> availability of the Home Depot website and are reflected by an underlying >> coding weakness of relying on or incorporating improperly licensed >> components. Home Depot would not have a choice or voluntary decision in >> such a case, and even if it did, it's still a quantifiable threat to the >> software. >> >> >> >> “If we put license issues in CWE, then we might as well put rising >> energy costs in CWE.” Whether the energy is cut off through physical means >> (battery overload) or you can find a repeatable way to intentionally get a >> reliable power source shut off because the user can’t pay the power bill, >> it’s still a valid CWE-920 in my opinion. Likewise, whether you force >> license adherence with license management software or request that your >> users adhere to it voluntarily, it’s still an availability vulnerability >> that should also have a CWE to categorize it. >> >> >> >> Thank you for helping me understand the position better. I do not think I >> agree with it, but do understand the position better than I did before. >> >> >> >> Jon >> >> >> >> *From:* Hatfield, Arthur <[email protected]> >> *Sent:* Thursday, November 9, 2023 9:54 AM >> *To:* Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) < >> [email protected]>; Przemyslaw Roguski <[email protected]>; >> Steven M Christey <[email protected]> >> *Cc:* CWE Research Discussion <[email protected]> >> *Subject:* Re: [Non-DoD Source] Re: Request for CWE: Improper Licensing >> (UNCLASSIFIED) >> >> >> >> You don't often get email from [email protected]. Learn why >> this is important <https://aka.ms/LearnAboutSenderIdentification> >> >> Look at it this way: >> >> >> >> Licensing issues are not a property of software, but of the society and >> economy around the software. >> >> >> >> A buffer overflow in a driver will crash your computer and make it >> unavailable any time data passes through it in a particular way, no matter >> who is causing that data to go through that buffer or why. A GPL-violation >> lawsuit will only stop you from distributing software if you voluntarily >> settle or you lose the lawsuit, and even then that’s basically going to >> require voluntary action on your part to stop using and/or distributing the >> software. It doesn’t do anything to stop the execution of that software on >> any system not under your direct control where it’s already running. >> Availability of the software in this case is not affected by a “coding >> weakness,” but by your organizational response to social, legal, and >> economic pressure. >> >> >> >> If we put license issues in CWE, then we might as well put rising energy >> costs in CWE. A surprise jump in your power bill could affect the >> availability of your application if you respond to the bill by voluntarily >> turning off your computer. >> >> >> >> >> >> *RT Hatfield* *|* *Staff Cybersecurity Analyst **|* *BS CS, CCITP, CISSP* >> >> *The Home Depot | **Cyber Threat Intelligence* >> >> * [email protected] >> >> * [email protected] >> >> >> >> >> >> >> >> >> >> >> >> INTERNAL USE >> >> *From: *Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) < >> [email protected]> >> *Date: *Thursday, November 9, 2023 at 10:26 AM >> *To: *Przemyslaw Roguski <[email protected]>, Steven M Christey < >> [email protected]> >> *Cc: *CWE Research Discussion <[email protected]> >> *Subject: *[EXTERNAL] [EXT] RE: [Non-DoD Source] Re: Request for CWE: >> Improper Licensing (UNCLASSIFIED) >> >> I respectfully disagree with this. Using a license incorrectly causes an >> availability issue directly, and availability is one of the cybersecurity >> principles that represent weaknesses and vulnerabilities by the definitions >> I am aware of. >> >> >> >> Can you please help me understand what definition CWE is using for each? >> The nearest definitions I can find are: “A ‘weakness’ is a condition in a >> software, firmware, hardware, or service component that, under certain >> circumstances, could contribute to the introduction of vulnerabilities” ( >> https://cwe.mitre.org/about/new_to_cwe.html). Following the >> vulnerability theory ( >> https://cwe.mitre.org/documents/vulnerability_theory/intro.html) >> suggests that we need to have a PRODUCT implementing FEATURE by performing >> certain BEHAVIORS that operate on RESOURCES. I will assume these >> definitions in my disagreement below, and acknowledge that my basic >> definitions of some of these terms may be off. >> >> >> >> The core question is therefore: is a license violation a vulnerability by >> the vulnerability theory used by the CWEs? I argue in the affirmative. You >> state, “No doubt that invalid licenses are a serious problem from the >> security perspective, but it's more a supply chain issue and legal >> problem.” Then a PRODUCT implementing software with a “supply chain issue” >> or “legal problem” to achieve its behavior on its resources produces an >> availability security impact against PRODUCT. If you want to identify it >> more generally as “supply chain issue” or “legal insufficiency,” it’s still >> a vulnerability that directly affects availability, incurs technical debt, >> and inflicts reputation/brand damage ( >> https://cwe.mitre.org/cwraf/creatingyourownvignettes.html). I believe >> that more specific supply chain or legal issues are appropriate as well >> (and license violations would be a specific example), but these two general >> classes of vulnerabilities you’ve identified also meet the criteria for >> becoming a CWE. CWE-1357 almost meets some of this definition as well. >> Instead of a license-violating component being “not sufficiently trusted to >> meet expectations for security” (with availability being part of the >> security definition), it would be nice to have a CWE that can refer to a >> component (trusted or not) that in fact does not meet security expectations >> because of “supply chain” or “legal” vulnerabilities. >> >> >> >> Can you please further explain why a “supply chain issue and legal >> problem” is an abuse of the weakness definition? I feel like you >> acknowledge it’s a weakness while also saying it’s an abuse of the >> definition of a weakness, which indicates that I’m not understanding some >> of your argument. You lose me at “Invalid license itself cannot lead to a >> vulnerability just like that.” How is a coding weakness that affects >> availability not a distinct, individual vulnerability, regardless of what >> other vulnerabilities may also be in the software? >> >> >> >> Sincere thanks for your response and interaction, >> >> Jon >> >> >> >> *From:* Przemyslaw Roguski <[email protected]> >> *Sent:* Sunday, November 5, 2023 1:21 PM >> *To:* Steven M Christey <[email protected]> >> *Cc:* Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) < >> [email protected]>; CWE Research Discussion < >> [email protected]> >> *Subject:* [Non-DoD Source] Re: Request for CWE: Improper Licensing >> (UNCLASSIFIED) >> >> >> >> You don't often get email from [email protected]. Learn why this is >> important <https://aka.ms/LearnAboutSenderIdentification> >> >> Hi All, >> >> >> >> In my personal opinion, adding new weakness or renaming existing one to >> something more "licensing" related is abuse of the weakness definition. >> >> We defined the weakness and vulnerability definitions a long time ago and >> any licensing problems do not fit the weakness use case. >> >> >> >> The real-world examples provided in this thread indicate that there were >> license problems, but it's only a side effect of the problem. >> >> Let me explain it in a different way. If you use a component or 3rd party >> software where it is a good, correct licence, but that component is not >> maintained correctly or has some vulnerabilities that some day lead to an >> exploit and successful attack, then it doesn't matter that there was a >> correct licence. >> No doubt that invalid licenses are a serious problem from the security >> perspective, but it's more a supply chain issue and legal problem. >> >> Invalid licence itself cannot lead to a vulnerability just like that. >> There must be another weakness that can lead to a vulnerability. >> >> Licences should be registered and monitored similarly to the components >> (artifacts) provenance, which is in scope of SBOMs. >> >> Hence adding a new weakness licensing related is not a good idea in my >> opinion. >> >> >> >> Best regards, >> >> Przemek >> >> >> >> *Przemyslaw Roguski* >> >> Security Architect, Product Security >> >> Red Hat Poland <https://www.redhat.com/> >> >> [email protected] IM: rogue >> >> [image: Image removed by sender.] <https://red.ht/sig> >> >> >> >> On Fri, Nov 3, 2023 at 4:30 PM Steven M Christey <[email protected]> wrote: >> >> All, >> >> >> >> While “licensing problems” per se does not have any direct coverage in >> CWE, there are indirect implications for security, e.g., it affects >> maintainability and might affect ability to apply security patches. >> >> >> >> Since 2018, we’ve added several newer CWE entries related to system >> components that might already be applicable; we could possibly modify one >> of them to name licensing as a consideration. >> >> >> >> The most applicable would be CWE-1357: Reliance on Insufficiently >> Trustworthy Component. “The product is built from multiple separate >> components, but it uses a component that is not sufficiently trusted to >> meet expectations for security, reliability, updateability, and >> maintainability.” >> >> >> >> Other CWEs in the same general area: >> >> >> >> 1. CWE-1104: Use of Unmaintained Third Party Components (child of >> CWE-1357) >> 2. CWE-1329: Reliance on Component That is Not Updateable (child of >> CWE-1357) >> 3. CWE-1395: Dependency on Vulnerable Third-Party Component >> >> >> >> >> >> I’d argue that there is already some overlap between these CWE entries, >> which we want to avoid as much as possible in CWE. So I would want to be >> very careful about creating a brand-new CWE just for licensing. >> >> >> >> Adapting the phrasing of the original proposal, it seems possible that a >> new "Use of Unauthorized Software" CWE could be created that is a parent of >> CWE-1357. However, there would need to be a strong case made that it isn’t >> an exact duplicate, i.e., are there weaknesses in this area that can NOT be >> described as “insufficiently trustworthy” in this sense? >> >> >> >> Any other input is welcome. >> >> >> >> - Steve >> >> >> >> >> >> *From:* Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) < >> [email protected]> >> *Sent:* Wednesday, November 1, 2023 10:49 AM >> *To:* CWE Research Discussion <[email protected]> >> *Subject:* [EXT] RE: Request for CWE: Improper Licensing (UNCLASSIFIED) >> >> >> >> I did want to renew this discussion. In light of the increased focus on >> supply chain risk management and composition analysis, the licensing issues >> and weaknesses in aggregated software are becoming more of a problem. Being >> able to categorize these weaknesses meaningfully would be helpful. >> >> >> >> Jon >> >> >> >> -----Original Message----- >> From: Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) >> Sent: Monday, October 15, 2018 5:01 PM >> To: Kurt Seifried <[email protected]>; Christey, Steven M. < >> [email protected]> >> Cc: Wheeler, David A CTR (US) <[email protected]>; Buttner, Drew < >> [email protected]>; CWE Research Discussion <[email protected] >> > >> Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED) >> >> >> >> CLASSIFICATION: UNCLASSIFIED >> >> >> >> I wanted to add another data point to this: suppose that there's a >> project that falls under DFARS Regulation 252.227-7014 ( >> https://www.acq.osd.mil/dpap/dars/dfars/html/current/252227.htm#252.227-7014), >> but the new contractor tries to use the software commercially. This could >> have been "exploited by an attacker" by suing the program, legal >> confiscation, or a fielding stay injunction. >> >> >> >> Real-world examples: >> >> • ReactOS: https://en.wikipedia.org/wiki/ReactOS#Internal_audit >> >> • MySQL AB: >> https://www.theregister.co.uk/2002/11/21/mysql_nusphere_settle_gpl_contract/ >> >> In both of these cases, the integrity of the software was allegedly >> tainted, and availability of the software (ReactOS through their website, >> and MySQL through NuSphere) was demonstrably compromised. >> >> • Artifex v. Hancom — Hancom stopped distributing that portion of their >> software, again exploiting the availability. >> >> >> >> That being said, it's difficult to articulate the specific technical >> exploitation path without also including other intangible weaknesses such >> as "Susceptible to DMCA takedown notices" or "Written by a lawsuit-happy >> contractor." >> >> >> >> Perhaps an "Unauthorized use of software" CWE would cover the multitude >> of issues behind the licensing. It has a tangible behavior (using >> unauthorized software), a specified resource (the software, involved >> patents, licensing, and/or policies), a violation of desired properties >> (written permission to use the software), and several exploitation paths: >> >> • lawsuit >> >> • confiscation >> >> • DMCA takedown >> >> >> >> Jon >> >> >> >> -----Original Message----- >> >> From: Kurt Seifried [mailto:[email protected] <[email protected]>] >> >> Sent: Thursday, August 23, 2018 3:11 PM >> >> To: Christey, Steven M. <[email protected]> >> >> Cc: Wheeler, David A CTR (US) <[email protected]>; Buttner, Drew < >> [email protected]>; CWE Research Discussion <[email protected] >> > >> >> Subject: [Non-DoD Source] Re: Request for CWE: Improper Licensing >> (UNCLASSIFIED) >> >> >> >> All active links contained in this email were disabled. Please verify the >> identity of the sender, and confirm the authenticity of all links contained >> within the message prior to copying and pasting the address to a Web >> browser. >> >> >> >> >> >> ________________________________ >> >> >> >> >> >> >> >> I would class it more as an exposure type of issue, in that while not >> directly exploitable it does open you up to new problems that didn't exist >> before. Like a freeze attack on an update server, I can't diretly exploit >> that to hack a box, but if I prevent you getting updates for a while, >> eventually you'll be vulnerable to something I can exploit. >> >> >> >> On Thu, Aug 23, 2018 at 1:49 PM, Christey, Steven M. <[email protected] < >> Caution-mailto:[email protected] >> <[email protected]%20%3c%20Caution-mailto:[email protected]%20>> > wrote: >> >> >> >> >> >> Using a general phrase of "Licensing Issue" is not >> particularly appropriate for CWE in that, typically, we try to write CWE >> descriptions that describe <behaviors> that operate on <resources> in ways >> that violate desired <properties> that, under the right circumstances, can >> be exploited by <attackers> to cross a security boundary. There's a >> similar approach for names, specifically so that generic terms like "issue" >> don't mislead CWE users into thinking they understand a CWE when doing >> mapping. >> >> >> >> I still find it difficult to figure out where or how >> attackers play a role in terms of licensing, although the role of licensing >> changes in delaying or preventing security patches does resonate with me - >> the system can be put into a state that attackers can exploit. However, >> there are many other programmer practices like "not having a complete test >> set" or "setting bug report to wrong fix priority" or any of dozens of >> other practices that I'm not sure we're quite ready to include in CWE yet. >> >> >> >> Note - I'm not stating any kind of official position on >> how/whether CWE should include licensing, just some thoughts. >> >> >> >> - Steve >> >> >> >> -- >> >> >> >> Kurt Seifried >> >> [email protected] < Caution-mailto:[email protected] > >> >> CLASSIFICATION: UNCLASSIFIED >> >> >> >> *From:* Wheeler, David A [email protected] >> *Sent:* Wednesday, August 22, 2018 11:36 AM >> *To:* Kurt Seifried [email protected]; Buttner, Drew [email protected] >> *Cc:* CWE Research Discussion [email protected] >> *Subject:* [Non-DoD Source] RE: Request for CWE: Improper Licensing >> (UNCLASSIFIED) >> >> >> >> All active links contained in this email were disabled. Please verify the >> identity of the sender, and confirm the authenticity of all links contained >> within the message prior to copying and pasting the address to a Web >> browser. >> ------------------------------ >> >> >> >> I agree that improper licensing (overall) is a problem, but I think there >> needs to be at least one more specific CWE as well: “License change forbids >> previously allowed activity”. Presumably this would be a sub-category. >> >> >> >> In **both** of the cases you cite, it **was** okay to do something in >> one version, but the newer version changed to a license that forbid >> previously-allowed activities. It is this **change** of license that is >> especially likely to cause problems, since people often don’t re-review >> licenses when they simply upgrade a component. In particular, lawyers >> often get involved reviewing licenses when components are **first** >> brought in, but often no one knows to even **check** that there’s been a >> significant change in conditions. >> >> >> >> --- David A. Wheeler >> >> >> >> *From:* Kurt Seifried [Caution-mailto:[email protected]] >> *Sent:* Wednesday, August 22, 2018 12:03 PM >> *To:* Buttner, Drew >> *Cc:* CWE Research Discussion >> *Subject:* Re: Request for CWE: Improper Licensing (UNCLASSIFIED) >> >> >> >> So some new stuff has come to light recently: >> >> >> >> 1) Caution-https://redislabs.com/community/commons-clause/ < Caution- >> https://redislabs.com/community/commons-clause/ > >> >> >> >> 2) Caution- >> https://www.theregister.co.uk/AMP/2018/08/21/intel_cpu_patch_licence/ >> < Caution- >> https://www.theregister.co.uk/AMP/2018/08/21/intel_cpu_patch_licence/ > >> >> >> >> so in case #1 we now have a situation where cloud providers and other >> places cannot update redis components if they sell it as a service due to >> the license changes. In case #2 we have Debian users left with a VERY a >> painful set of steps to take to manually update the microcode (rather than >> linux just magically doing it at boot time). >> >> >> >> I think in light of the above we should revisit this CWE and consider it >> for inclusion as it clearly has real world consequences and is becoming a >> problem. >> >> >> >> On Mon, May 21, 2018 at 8:46 AM, Buttner, Drew < >> [email protected] < Caution-mailto:[email protected] >> <[email protected]%C2%A0%3c%C2%A0Caution-mailto:[email protected]>> > >> wrote: >> >> CWE Community, >> >> Thank you to all that weighed in on this topic and added to the >> discussion earlier this month. The CWE team found the discussion very >> enlightening, and it really helped us understand this issue that we didn't >> know much about. However, our feeling is that improper licensing is outside >> of CWE's current scope. Although it is a way to impact software and its >> usage, we feel that this is not through the technical exploitation of a >> software security weakness in architecture, design, or code. Rather, it is >> though policy/programmatic exploitation. >> >> Looking at the hypothetical example provided, software that includes some >> improper licenses may be forced offline and become unavailable, but >> technically the software still works as intended. This is very different >> from a weakness in how resources are managed that causes an application to >> allocate all its handles and then become unavailable. The availability >> issue with licensing surrounds a policy that the software shall no longer >> be used. In many ways, there is similarity here with supply chain issues >> where one disrupts a supplier to stop/limit a product from being delivered, >> and hence make it not available. >> >> We feel that these types of issues, although legitimate, are not within >> the current scope of CWE which focuses on architecture, design, and coding >> weaknesses. >> >> Going forward, we will be looking to expand the scope of CWE to include >> certain quality related issue. As this happens, the scope may broaden to >> include some issues similar to improper licensing and within areas beyond >> the three mentioned above. If that is the case, then this discussion we be >> brought back to the forefront. >> >> We are still open for discussion on either the specific issue, or with >> our defined scope. We very much value feedback so please don't hesitate to >> share opinions if you have them. >> >> Thanks >> Drew >> >> >> >> -----Original Message----- >> From: [email protected] < Caution-mailto: >> [email protected] > [Caution-mailto: >> [email protected] < Caution-mailto: >> [email protected] > ] On Behalf Of Hood, Jonathan >> W CTR USARMY RDECOM AMRDEC (US) >> Sent: Monday, April 30, 2018 10:52 AM >> To: cwe-research-list CWE Research Discussion < >> [email protected] < >> Caution-mailto:[email protected] >> <[email protected]%C2%A0%3c%C2%A0Caution-mailto:[email protected]> >> > > >> Subject: Request for CWE: Improper Licensing (UNCLASSIFIED) >> >> CLASSIFICATION: UNCLASSIFIED >> >> CWE Team, >> >> We've run into cases where a software license is being violated. A few >> generalized scenarios we've run into lately: >> • Someone violates the GPL in one of the many ways that the GPL can be >> violated (I'm not going to elaborate on this much; I like the GPL and am >> only using it as an example of a very-easy-to-violate license) • Someone >> partners with a school on an STTR from the government >> ⁃ The school assigns the task to a poor grad student >> ⁃ The grad student implements the academic license of a library >> they want to use >> ⁃ The grad student turns in a working solution with the academic >> license unknowingly embedded >> ⁃ The PI on the STTR turns in the working solution >> ⁃ The working solution is incorporated into a commercial project >> without switching to the commercial version of the dependency • Someone >> copyrights and licenses their software in an overly-restrictive or illegal >> way (re: Bayh-Dole Act IP with "royalty-free use by or on behalf of the >> government") >> >> Usually, the software team is ignorant of the issue they've introduced >> with the licenses. Nevertheless, inherent legal issues become cybersecurity >> concerns, especially when they can affect the availability and rights to >> use the software. >> >> Proposed CWE Title: Improper Licensing >> >> Impacts: Availability >> >> Description: Licensing issues indicate poor adherence to copyrights and >> other legal requirements. License violations can take many forms, and each >> can be costly to an organization. Several include: >> • Reliance, in a commercial solution, on software licensed for >> non-commercial use only. >> • Use of expired licenses >> • Including unlicensed components into a solution • Violating a license's >> terms • Placing software under an illegal or overly-restrictive license >> Each issue introduces legal risks that can affect the availability of the >> solution. >> >> Modes of Introduction: Implementation >> >> Applicable Platforms: All >> >> Likelihood of Exploit: Low >> >> I'm in favor of having a catch-all licensing issue CWE. Alternatively, >> higher fidelity may be achieved by creating a category and CWE hierarchy: >> • Category: Licensing Issues >> ⁃ CWE: Reliance on Incorrect License >> ⁃ CWE: Use of Expired License >> ⁃ CWE: Reliance on Unlicensed Component >> ⁃ CWE: Improper Adherence to License Terms >> ⁃ CWE: Institution of an Overly-Restrictive or Illegal License >> >> This may need to be moved under the CQEs once they are merged with CWEs. >> >> Jon >> >> >> ------------------------------ >> >> >> The information in this Internet Email is confidential and may be legally >> privileged. It is intended solely for the addressee. Access to this Email >> by anyone else is unauthorized. If you are not the intended recipient, any >> disclosure, copying, distribution or any action taken or omitted to be >> taken in reliance on it, is prohibited and may be unlawful. When addressed >> to our clients any opinions or advice contained in this Email are subject >> to the terms and conditions expressed in any applicable governing The Home >> Depot terms of business or client engagement letter. The Home Depot >> disclaims all responsibility and liability for the accuracy and content of >> this attachment and for any damages or losses arising from any >> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other >> items of a destructive nature, which may be contained in this attachment >> and shall not be liable for direct, indirect, consequential or special >> damages in connection with this e-mail message or its attachment. >> > -- Kurt Seifried (He/Him) [email protected]
