RE: [EXTERNAL]: Re: [External] - Re: Bad loop construct
I agree with Shravan. Stand-alone use cases may be a small percentage of total usage, but there are business cases where it is absolutely critical. From: Mahidhara, Shravan Sent: Wednesday, June 1, 2022 9:58 AM To: Kurt Seifried ; Kevin Keen Cc: Steve Grubb ; Steven M Christey ; CWE Research Discussion Subject: RE: [EXTERNAL]: Re: [External] - Re: Bad loop construct WARNING: This email originated from outside of the organization. DO NOT click links, open attachments, or respond unless you recognize the sender and know the content is safe. There are numerous systems that do not need an active internet connection to run software and carry out their functions. A quick example is software running on geographically distributed systems used in industries like transportation, mining, etc. Do these systems need external connectivity to download software? Yes. Do they need always-on connectivity to run the software and execute their steady state functions? Absolutely not. I agree that we probably need to better account for the cloud space, but to state that there is not so much a case for standalone software is incorrect. Regards, Shravan From: Kurt Seifried mailto:k...@seifried.org>> Sent: Wednesday, June 1, 2022 8:32 AM To: Kevin Keen mailto:kk...@colsa.com>> Cc: Steve Grubb mailto:sgr...@redhat.com>>; Steven M Christey mailto:co...@mitre.org>>; CWE Research Discussion mailto:cwe-research-list@mitre.org>> Subject: [EXTERNAL]: Re: [External] - Re: Bad loop construct I’d challenge you to use your phone or computer without an internet connection. Realistically for the work and activity most engage in on compute devices, connected software is the default now. On Jun 1, 2022, at 7:12 AM, Kevin Keen mailto:kk...@colsa.com>> ZjQcmQRYFpfptBannerStart Be Careful With This Message The sender's identity could not be verified and someone may be impersonating the sender. Please use caution responding to this email or opening any attachments. ZjQcmQRYFpfptBannerEnd I’d challenge you to use your phone or computer without an internet connection. Realistically for the work and activity most engage in on compute devices, connected software is the default now. On Jun 1, 2022, at 7:12 AM, Kevin Keen mailto:kk...@colsa.com>> wrote: I agree that CWEs could use some updates. In addition to possible new CWEs, I remember looking at a few that didn't have code examples and thinking that they could benefit from that. I would however, push back just a little on stand alone software not being a common case. I think it depends on your area. For the average at home user a trend toward cloud is probably true. But we see a lot of software in the field I'm in and it is rarely ever cloud based. From: Kurt Seifried mailto:k...@seifried.org>> Sent: Tuesday, May 31, 2022 8:21 PM To: Steve Grubb mailto:sgr...@redhat.com>> Cc: Steven M Christey mailto:co...@mitre.org>>; CWE Research Discussion mailto:cwe-research-list@mitre.org>> Subject: [External] - Re: Bad loop construct CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On a related item, I'm doing a CWE a week with my Smartcontracts working group (~10 total and then we'll release a short paper on it at the end of summer) at the Cloud Security Alliance. Longer term my plan is to look at all the stuff covered in places like rekt.news or Microsoft blog entries and so on, and make sure it maps cleanly to a CWE, and if not, to make a CWE for it. E.g. so far: [cid:image001.png@01D875A5.2AAAF450] I've submitted 1, 3, and 4 so far, and 5 are going in next week (3 for 1 sale =). In my mind every CVE/vuln/etc writeup should map to a CWE, and I don't mean CWE-20. We literally need a few hundred more CWE's, especially in the smart contract/blockchain space, and the Cloud SaaS space. CWE is showing its age with respect to "software" being something you download and run locally. That's not the case so much anymore. On Tue, May 31, 2022 at 3:30 PM Steve Grubb mailto:sgr...@redhat.com>> wrote: Hello everyone, On Tuesday, May 24, 2022 5:49:57 PM EDT Steven M Christey wrote: > Kurt said “I've seen code with loops of one because of future growth, or > because various options were removed and it's easier than refactoring the > code” – so a CWE-related writeup wouldn’t want to inadvertently call all > loops of size 1 “bad.” From what I can see, it's a mixed bag. There are cases like Kurt mentioned, but also some that are thinko's. > But remember that a weakness is about a that only becomes a > vulnerability Code analysis tools report > weaknesses all the time, but determining false positives is a different &
RE: [EXTERNAL]: Re: [External] - Re: Bad loop construct
There are numerous systems that do not need an active internet connection to run software and carry out their functions. A quick example is software running on geographically distributed systems used in industries like transportation, mining, etc. Do these systems need external connectivity to download software? Yes. Do they need always-on connectivity to run the software and execute their steady state functions? Absolutely not. I agree that we probably need to better account for the cloud space, but to state that there is not so much a case for standalone software is incorrect. Regards, Shravan From: Kurt Seifried Sent: Wednesday, June 1, 2022 8:32 AM To: Kevin Keen Cc: Steve Grubb ; Steven M Christey ; CWE Research Discussion Subject: [EXTERNAL]: Re: [External] - Re: Bad loop construct I’d challenge you to use your phone or computer without an internet connection. Realistically for the work and activity most engage in on compute devices, connected software is the default now. On Jun 1, 2022, at 7:12 AM, Kevin Keen mailto:kk...@colsa.com>> ZjQcmQRYFpfptBannerStart Be Careful With This Message The sender's identity could not be verified and someone may be impersonating the sender. Please use caution responding to this email or opening any attachments. ZjQcmQRYFpfptBannerEnd I’d challenge you to use your phone or computer without an internet connection. Realistically for the work and activity most engage in on compute devices, connected software is the default now. On Jun 1, 2022, at 7:12 AM, Kevin Keen mailto:kk...@colsa.com>> wrote: I agree that CWEs could use some updates. In addition to possible new CWEs, I remember looking at a few that didn't have code examples and thinking that they could benefit from that. I would however, push back just a little on stand alone software not being a common case. I think it depends on your area. For the average at home user a trend toward cloud is probably true. But we see a lot of software in the field I'm in and it is rarely ever cloud based. From: Kurt Seifried mailto:k...@seifried.org>> Sent: Tuesday, May 31, 2022 8:21 PM To: Steve Grubb mailto:sgr...@redhat.com>> Cc: Steven M Christey mailto:co...@mitre.org>>; CWE Research Discussion mailto:cwe-research-list@mitre.org>> Subject: [External] - Re: Bad loop construct CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On a related item, I'm doing a CWE a week with my Smartcontracts working group (~10 total and then we'll release a short paper on it at the end of summer) at the Cloud Security Alliance. Longer term my plan is to look at all the stuff covered in places like rekt.news or Microsoft blog entries and so on, and make sure it maps cleanly to a CWE, and if not, to make a CWE for it. E.g. so far: [cid:image001.png@01D8759E.1110B5E0] I've submitted 1, 3, and 4 so far, and 5 are going in next week (3 for 1 sale =). In my mind every CVE/vuln/etc writeup should map to a CWE, and I don't mean CWE-20. We literally need a few hundred more CWE's, especially in the smart contract/blockchain space, and the Cloud SaaS space. CWE is showing its age with respect to "software" being something you download and run locally. That's not the case so much anymore. On Tue, May 31, 2022 at 3:30 PM Steve Grubb mailto:sgr...@redhat.com>> wrote: Hello everyone, On Tuesday, May 24, 2022 5:49:57 PM EDT Steven M Christey wrote: > Kurt said “I've seen code with loops of one because of future growth, or > because various options were removed and it's easier than refactoring the > code” – so a CWE-related writeup wouldn’t want to inadvertently call all > loops of size 1 “bad.” From what I can see, it's a mixed bag. There are cases like Kurt mentioned, but also some that are thinko's. > But remember that a weakness is about a that only becomes a > vulnerability Code analysis tools report > weaknesses all the time, but determining false positives is a different > story that’s not in CWE’s purview. Similarly, external parties can decide > which CWEs become a “requirement” or not – it’s primarily CWE’s > responsibility to provide the identifier and explanation for the mistake, > and how it can (at least sometimes) contribute to vulnerabilities. > > In this “dir” example, we can’t be clear whether the developer made a > mistake or not. But we can observe that there’s a loop construct with only > one element, and that it’s (sometimes) going to be a mistake. And it seems > like such constructs could occur in most languages. > > I’m not sure how deep CWE should go to cover “just bad syntax,” but for > this example, I think CWE-670 is probably the closest match in spirit – &
Re: [External] - Re: Bad loop construct
I agree you all are pain in the ass. Keep spamming my mailbox. On Wed, 1 Jun 2022, 9:13 pm Kevin Keen, wrote: > > I agree that CWEs could use some updates. In addition to possible new > CWEs, I remember looking at a few that didn't have code examples and > thinking that they could benefit from that. > > > I would however, push back just a little on stand alone software not being > a common case. I think it depends on your area. For the average at home > user a trend toward cloud is probably true. But we see a lot of software in > the field I'm in and it is rarely ever cloud based. > -- > *From:* Kurt Seifried > *Sent:* Tuesday, May 31, 2022 8:21 PM > *To:* Steve Grubb > *Cc:* Steven M Christey ; CWE Research Discussion < > cwe-research-list@mitre.org> > *Subject:* [External] - Re: Bad loop construct > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > On a related item, I'm doing a CWE a week with my Smartcontracts working > group (~10 total and then we'll release a short paper on it at the end of > summer) at the Cloud Security Alliance. Longer term my plan is to look at > all the stuff covered in places like rekt.news or Microsoft blog entries > and so on, and make sure it maps cleanly to a CWE, and if not, to make a > CWE for it. E.g. so far: > [image: Screenshot 2022-05-31 191808.png] > > I've submitted 1, 3, and 4 so far, and 5 are going in next week (3 for 1 > sale =). In my mind every CVE/vuln/etc writeup should map to a CWE, and I > don't mean CWE-20. > > We literally need a few hundred more CWE's, especially in the smart > contract/blockchain space, and the Cloud SaaS space. CWE is showing its age > with respect to "software" being something you download and run locally. > That's not the case so much anymore. > > > On Tue, May 31, 2022 at 3:30 PM Steve Grubb wrote: > > Hello everyone, > > On Tuesday, May 24, 2022 5:49:57 PM EDT Steven M Christey wrote: > > Kurt said “I've seen code with loops of one because of future growth, or > > because various options were removed and it's easier than refactoring the > > code” – so a CWE-related writeup wouldn’t want to inadvertently call all > > loops of size 1 “bad.” > > From what I can see, it's a mixed bag. There are cases like Kurt > mentioned, > but also some that are thinko's. > > > But remember that a weakness is about a that only becomes a > > vulnerability Code analysis tools report > > weaknesses all the time, but determining false positives is a different > > story that’s not in CWE’s purview. Similarly, external parties can decide > > which CWEs become a “requirement” or not – it’s primarily CWE’s > > responsibility to provide the identifier and explanation for the mistake, > > and how it can (at least sometimes) contribute to vulnerabilities. > > > > In this “dir” example, we can’t be clear whether the developer made a > > mistake or not. But we can observe that there’s a loop construct with > only > > one element, and that it’s (sometimes) going to be a mistake. And it > seems > > like such constructs could occur in most languages. > > > > I’m not sure how deep CWE should go to cover “just bad syntax,” but for > > this example, I think CWE-670 is probably the closest match in spirit – > > the algorithm (probably) isn’t implementing the logic that the programmer > > thought they were implementing. There’s a good argument for CWE-1164 as > > well, though, since the developer might be doing this intentionally even > > though the code is not technically essential. > > In the end, we chose 1164. It was added to a csv file where we are > cateloging > warnings from a couple tools and mapping to CWE. It is here in case anyone > finds it useful: > > https://github.com/csutils/csmock/blob/main/cwe-map.csv > <https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fgithub.com%2Fcsutils%2Fcsmock%2Fblob%2Fmain%2Fcwe-map.csv&data=05%7C01%7Ckkeen%40colsa.com%7Cf518d89fcb464d325ecb08da436d4ba5%7C9821086b78824b43a5edb1e979bee31f%7C1%7C0%7C637896433982029055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=O4u39YUHsyfUDc3141c8pXCXDoQ3yKlZAjmB%2BZxaQN0%3D&reserved=0> > > Thanks for the help! > > -Steve > > > > > -- > Kurt Seifried (He/Him) > k...@seifried.org > -- > The information contained in this e-mail and any attachments from COLSA > Corporation m
Re: [External] - Re: Bad loop construct
I agree that CWEs could use some updates. In addition to possible new CWEs, I remember looking at a few that didn't have code examples and thinking that they could benefit from that. I would however, push back just a little on stand alone software not being a common case. I think it depends on your area. For the average at home user a trend toward cloud is probably true. But we see a lot of software in the field I'm in and it is rarely ever cloud based. From: Kurt Seifried Sent: Tuesday, May 31, 2022 8:21 PM To: Steve Grubb Cc: Steven M Christey ; CWE Research Discussion Subject: [External] - Re: Bad loop construct CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On a related item, I'm doing a CWE a week with my Smartcontracts working group (~10 total and then we'll release a short paper on it at the end of summer) at the Cloud Security Alliance. Longer term my plan is to look at all the stuff covered in places like rekt.news or Microsoft blog entries and so on, and make sure it maps cleanly to a CWE, and if not, to make a CWE for it. E.g. so far: [Screenshot 2022-05-31 191808.png] I've submitted 1, 3, and 4 so far, and 5 are going in next week (3 for 1 sale =). In my mind every CVE/vuln/etc writeup should map to a CWE, and I don't mean CWE-20. We literally need a few hundred more CWE's, especially in the smart contract/blockchain space, and the Cloud SaaS space. CWE is showing its age with respect to "software" being something you download and run locally. That's not the case so much anymore. On Tue, May 31, 2022 at 3:30 PM Steve Grubb mailto:sgr...@redhat.com>> wrote: Hello everyone, On Tuesday, May 24, 2022 5:49:57 PM EDT Steven M Christey wrote: > Kurt said “I've seen code with loops of one because of future growth, or > because various options were removed and it's easier than refactoring the > code” – so a CWE-related writeup wouldn’t want to inadvertently call all > loops of size 1 “bad.” >From what I can see, it's a mixed bag. There are cases like Kurt mentioned, but also some that are thinko's. > But remember that a weakness is about a that only becomes a > vulnerability Code analysis tools report > weaknesses all the time, but determining false positives is a different > story that’s not in CWE’s purview. Similarly, external parties can decide > which CWEs become a “requirement” or not – it’s primarily CWE’s > responsibility to provide the identifier and explanation for the mistake, > and how it can (at least sometimes) contribute to vulnerabilities. > > In this “dir” example, we can’t be clear whether the developer made a > mistake or not. But we can observe that there’s a loop construct with only > one element, and that it’s (sometimes) going to be a mistake. And it seems > like such constructs could occur in most languages. > > I’m not sure how deep CWE should go to cover “just bad syntax,” but for > this example, I think CWE-670 is probably the closest match in spirit – > the algorithm (probably) isn’t implementing the logic that the programmer > thought they were implementing. There’s a good argument for CWE-1164 as > well, though, since the developer might be doing this intentionally even > though the code is not technically essential. In the end, we chose 1164. It was added to a csv file where we are cateloging warnings from a couple tools and mapping to CWE. It is here in case anyone finds it useful: https://github.com/csutils/csmock/blob/main/cwe-map.csv<https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fgithub.com%2Fcsutils%2Fcsmock%2Fblob%2Fmain%2Fcwe-map.csv&data=05%7C01%7Ckkeen%40colsa.com%7Cf518d89fcb464d325ecb08da436d4ba5%7C9821086b78824b43a5edb1e979bee31f%7C1%7C0%7C637896433982029055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=O4u39YUHsyfUDc3141c8pXCXDoQ3yKlZAjmB%2BZxaQN0%3D&reserved=0> Thanks for the help! -Steve -- Kurt Seifried (He/Him) k...@seifried.org<mailto:k...@seifried.org> The information contained in this e-mail and any attachments from COLSA Corporation may contain company sensitive and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments. COLSA Proprietary
Re: Bad loop construct
On a related item, I'm doing a CWE a week with my Smartcontracts working group (~10 total and then we'll release a short paper on it at the end of summer) at the Cloud Security Alliance. Longer term my plan is to look at all the stuff covered in places like rekt.news or Microsoft blog entries and so on, and make sure it maps cleanly to a CWE, and if not, to make a CWE for it. E.g. so far: [image: Screenshot 2022-05-31 191808.png] I've submitted 1, 3, and 4 so far, and 5 are going in next week (3 for 1 sale =). In my mind every CVE/vuln/etc writeup should map to a CWE, and I don't mean CWE-20. We literally need a few hundred more CWE's, especially in the smart contract/blockchain space, and the Cloud SaaS space. CWE is showing its age with respect to "software" being something you download and run locally. That's not the case so much anymore. On Tue, May 31, 2022 at 3:30 PM Steve Grubb wrote: > Hello everyone, > > On Tuesday, May 24, 2022 5:49:57 PM EDT Steven M Christey wrote: > > Kurt said “I've seen code with loops of one because of future growth, or > > because various options were removed and it's easier than refactoring the > > code” – so a CWE-related writeup wouldn’t want to inadvertently call all > > loops of size 1 “bad.” > > From what I can see, it's a mixed bag. There are cases like Kurt > mentioned, > but also some that are thinko's. > > > But remember that a weakness is about a that only becomes a > > vulnerability Code analysis tools report > > weaknesses all the time, but determining false positives is a different > > story that’s not in CWE’s purview. Similarly, external parties can decide > > which CWEs become a “requirement” or not – it’s primarily CWE’s > > responsibility to provide the identifier and explanation for the mistake, > > and how it can (at least sometimes) contribute to vulnerabilities. > > > > In this “dir” example, we can’t be clear whether the developer made a > > mistake or not. But we can observe that there’s a loop construct with > only > > one element, and that it’s (sometimes) going to be a mistake. And it > seems > > like such constructs could occur in most languages. > > > > I’m not sure how deep CWE should go to cover “just bad syntax,” but for > > this example, I think CWE-670 is probably the closest match in spirit – > > the algorithm (probably) isn’t implementing the logic that the programmer > > thought they were implementing. There’s a good argument for CWE-1164 as > > well, though, since the developer might be doing this intentionally even > > though the code is not technically essential. > > In the end, we chose 1164. It was added to a csv file where we are > cateloging > warnings from a couple tools and mapping to CWE. It is here in case anyone > finds it useful: > > https://github.com/csutils/csmock/blob/main/cwe-map.csv > > Thanks for the help! > > -Steve > > > -- Kurt Seifried (He/Him) k...@seifried.org
Re: Bad loop construct
Hello everyone, On Tuesday, May 24, 2022 5:49:57 PM EDT Steven M Christey wrote: > Kurt said “I've seen code with loops of one because of future growth, or > because various options were removed and it's easier than refactoring the > code” – so a CWE-related writeup wouldn’t want to inadvertently call all > loops of size 1 “bad.” >From what I can see, it's a mixed bag. There are cases like Kurt mentioned, but also some that are thinko's. > But remember that a weakness is about a that only becomes a > vulnerability Code analysis tools report > weaknesses all the time, but determining false positives is a different > story that’s not in CWE’s purview. Similarly, external parties can decide > which CWEs become a “requirement” or not – it’s primarily CWE’s > responsibility to provide the identifier and explanation for the mistake, > and how it can (at least sometimes) contribute to vulnerabilities. > > In this “dir” example, we can’t be clear whether the developer made a > mistake or not. But we can observe that there’s a loop construct with only > one element, and that it’s (sometimes) going to be a mistake. And it seems > like such constructs could occur in most languages. > > I’m not sure how deep CWE should go to cover “just bad syntax,” but for > this example, I think CWE-670 is probably the closest match in spirit – > the algorithm (probably) isn’t implementing the logic that the programmer > thought they were implementing. There’s a good argument for CWE-1164 as > well, though, since the developer might be doing this intentionally even > though the code is not technically essential. In the end, we chose 1164. It was added to a csv file where we are cateloging warnings from a couple tools and mapping to CWE. It is here in case anyone finds it useful: https://github.com/csutils/csmock/blob/main/cwe-map.csv Thanks for the help! -Steve
Re: [External] - RE: Bad loop construct
I think there's an easy way to distinguish "likely problem" from "likely false positive" in this case. If a shell loops over one value AND that value is the name a previously-assigned variable, that is likely a variable name missing its "$". Otherwise it's plausibly a loop over 1 value (which is a little odd, but not insane and such a construct is less likely to be an error). I doubt such a construct often leads to a vulnerability. It seems like the sort of thing likely to be detected in practically any testing, since it's deterministic & doesn't depend on attacker input at all. --- David A. Wheeler
Re: [External] - RE: Bad loop construct
I believe this is my first time posting to this list, so apologies if I'm stepping out of line. These comments are focused on the looping once aspect of this discussion. There is perhaps a 2nd aspect at play in Kurt's example with confusing naming, but I'm setting that aside for now. I feel like a loop that will always execute once should be considered a weakness. In the best case of "planning for the future" it reminds me of the code smell Speculative Generality, just at a lower level. At the very least it needlessly increases complexity and slightly hampers readability, and we have several CWEs that target other weaknesses for those reasons. It is worth stressing that just because a loop executes once does not mean it has this same problem. The problem is when the loop will always execute and always execute just once. Given the CWEs mentioned so far I think I like 1164 "Irrelevant Code" the best, but I feel like this particular issue should live under the 1226 "Complexity Issues" category. I suppose a very weak argument could be made for CWE 1121 "Excessive McCabe Cyclomatic Complexity". But a single loop is basically linear so that's quite a stretch. As a side note, we have run into several cases of other issues where the best match for something we were looking at was one of the members of "Complexity Issues", but the "excessive" part didn't really fit. Thanks! Kevin From: Steven M Christey Sent: Tuesday, May 24, 2022 4:49 PM To: Seifried, Kurt ; Grubb, Steve Cc: CWE Research Discussion Subject: [External] - RE: Bad loop construct CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Just some quick comments on this topic. It’s an interesting observation about shell languages being different than C. I know I’ve probably offended some co-workers recently with my initial attempts at bash scripting 😉 It feels to me like the syntax is somehow less stringent, but maybe the key difference is in interpreted languages versus compiled languages, combined with the lack of strict typing. Kurt said “I've seen code with loops of one because of future growth, or because various options were removed and it's easier than refactoring the code” – so a CWE-related writeup wouldn’t want to inadvertently call all loops of size 1 “bad.” But remember that a weakness is about a that only becomes a vulnerability Code analysis tools report weaknesses all the time, but determining false positives is a different story that’s not in CWE’s purview. Similarly, external parties can decide which CWEs become a “requirement” or not – it’s primarily CWE’s responsibility to provide the identifier and explanation for the mistake, and how it can (at least sometimes) contribute to vulnerabilities. In this “dir” example, we can’t be clear whether the developer made a mistake or not. But we can observe that there’s a loop construct with only one element, and that it’s (sometimes) going to be a mistake. And it seems like such constructs could occur in most languages. I’m not sure how deep CWE should go to cover “just bad syntax,” but for this example, I think CWE-670 is probably the closest match in spirit – the algorithm (probably) isn’t implementing the logic that the programmer thought they were implementing. There’s a good argument for CWE-1164 as well, though, since the developer might be doing this intentionally even though the code is not technically essential. For issues where there might be some varying opinions about whether some code choice is “good” or not, note that we also cover source code conventions with CWE-1078: Inappropriate Source Code Style or Formatting. It has some useful children. - Steve The information contained in this e-mail and any attachments from COLSA Corporation may contain company sensitive and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments. COLSA Proprietary
RE: Bad loop construct
Just some quick comments on this topic. It’s an interesting observation about shell languages being different than C. I know I’ve probably offended some co-workers recently with my initial attempts at bash scripting 😉 It feels to me like the syntax is somehow less stringent, but maybe the key difference is in interpreted languages versus compiled languages, combined with the lack of strict typing. Kurt said “I've seen code with loops of one because of future growth, or because various options were removed and it's easier than refactoring the code” – so a CWE-related writeup wouldn’t want to inadvertently call all loops of size 1 “bad.” But remember that a weakness is about a that only becomes a vulnerability Code analysis tools report weaknesses all the time, but determining false positives is a different story that’s not in CWE’s purview. Similarly, external parties can decide which CWEs become a “requirement” or not – it’s primarily CWE’s responsibility to provide the identifier and explanation for the mistake, and how it can (at least sometimes) contribute to vulnerabilities. In this “dir” example, we can’t be clear whether the developer made a mistake or not. But we can observe that there’s a loop construct with only one element, and that it’s (sometimes) going to be a mistake. And it seems like such constructs could occur in most languages. I’m not sure how deep CWE should go to cover “just bad syntax,” but for this example, I think CWE-670 is probably the closest match in spirit – the algorithm (probably) isn’t implementing the logic that the programmer thought they were implementing. There’s a good argument for CWE-1164 as well, though, since the developer might be doing this intentionally even though the code is not technically essential. For issues where there might be some varying opinions about whether some code choice is “good” or not, note that we also cover source code conventions with CWE-1078: Inappropriate Source Code Style or Formatting. It has some useful children. - Steve
Re: Bad loop construct
On Tue, May 24, 2022 at 12:24 PM Steve Grubb wrote: > On Tuesday, May 24, 2022 1:55:17 PM EDT Kurt Seifried wrote: > > On Tue, May 24, 2022 at 9:25 AM Steve Grubb wrote: > > > Hello, > > > > > > I am continuing to look at ShellCheck and how to map it's warnings to > > > CWE's. > > > I'm looking at SC2043 - This loop will only ever run once for a > constant > > > value. > > > > > > https://www.shellcheck.net/wiki/SC2043 > > > > > > An example might be: > > > > > > dir=$(ls $HOME) > > > for i in dir > > > do > > > > > > echo $i > > > > > > done > > > > > > which outputs "dir" because it's missing the "$" in the for statement. > > > > > > One of my thoughts is this could be CWE-606: Unchecked Input for Loop > > > Condition. It talks about unchecked inputs causing excessive looping. > > > What > > > about wrong input for loop conditional causing no iteration? > > > > > > Another thought is this could be CWE-670: Always-Incorrect Control Flow > > > Implementation. (But looking at that, I would have expected other bad > > > loop > > > nodes such as CWE-835: Loop with Unreachable Exit Condition.) > > > > > > Is there a better fit? Shell scripting problems really are a hard to > > > match > > > to > > > a CWE because it's problems are similar but very different than C. > > > > Hmm. What about the case where the dev puts in the values, e.g.: > > > > for VARIABLE in file1 file2 file3 > > do > > command1 on $VARIABLE > > done > > This ^^^ works fine. It iterates across the values. > > > which of course could be applied for a single thing as well (to afford > > future flexibility/etc): > > > > for VARIABLE in file1 > > do > > command1 on $VARIABLE > > done > > This ^^^ is another instance of the original issue because there is no > iteration. Could this be CWE-1164? Because you could reduce the whole > thing > down to > There is one iteration. I'm not going to argue semantics, but I would point out I've seen code with loops of one because of future growth, or because various options were removed and it's easier than refactoring the code. > > command file1 > > By removing deadcode. And that is what the warning is about. It's to say > take > a look at this - it doesn't make sense to go through the trouble of making > it > look like you wanted to loop and then you don't. > If we make removing deadcode a requirement... I'm going to be so glad I got out of the security response in OpenSource business =) > > > and then the question is "did the programmer mean to have a variable > called > > "dir" and an actual instance of a file or directory or whatever called > > "dir"? Probably not but maybe yes? > > Or they meant to add a /* after file1? In any event, I don't really find > any > satisfactory matching CWE. > > > > Maybe a more generic along the lines of are you using variables and > values > > that happen to share the same naming, e.g. "$dir" and "dir" which makes a > > mess much easier? > > And this is how the domain of shell differs from C or Java. Shell is happy > to > use the constant string "dir" instead of the variable $dir. It likely > isn't > what was intended. Or at least it deserves a look. > Maybe a "dangerous use of same string to identify different things" or "lack of variable prefix"? > > -Steve > > > -- Kurt Seifried (He/Him) k...@seifried.org
Re: Bad loop construct
On Tuesday, May 24, 2022 1:55:17 PM EDT Kurt Seifried wrote: > On Tue, May 24, 2022 at 9:25 AM Steve Grubb wrote: > > Hello, > > > > I am continuing to look at ShellCheck and how to map it's warnings to > > CWE's. > > I'm looking at SC2043 - This loop will only ever run once for a constant > > value. > > > > https://www.shellcheck.net/wiki/SC2043 > > > > An example might be: > > > > dir=$(ls $HOME) > > for i in dir > > do > > > > echo $i > > > > done > > > > which outputs "dir" because it's missing the "$" in the for statement. > > > > One of my thoughts is this could be CWE-606: Unchecked Input for Loop > > Condition. It talks about unchecked inputs causing excessive looping. > > What > > about wrong input for loop conditional causing no iteration? > > > > Another thought is this could be CWE-670: Always-Incorrect Control Flow > > Implementation. (But looking at that, I would have expected other bad > > loop > > nodes such as CWE-835: Loop with Unreachable Exit Condition.) > > > > Is there a better fit? Shell scripting problems really are a hard to > > match > > to > > a CWE because it's problems are similar but very different than C. > > Hmm. What about the case where the dev puts in the values, e.g.: > > for VARIABLE in file1 file2 file3 > do > command1 on $VARIABLE > done This ^^^ works fine. It iterates across the values. > which of course could be applied for a single thing as well (to afford > future flexibility/etc): > > for VARIABLE in file1 > do > command1 on $VARIABLE > done This ^^^ is another instance of the original issue because there is no iteration. Could this be CWE-1164? Because you could reduce the whole thing down to command file1 By removing deadcode. And that is what the warning is about. It's to say take a look at this - it doesn't make sense to go through the trouble of making it look like you wanted to loop and then you don't. > and then the question is "did the programmer mean to have a variable called > "dir" and an actual instance of a file or directory or whatever called > "dir"? Probably not but maybe yes? Or they meant to add a /* after file1? In any event, I don't really find any satisfactory matching CWE. > Maybe a more generic along the lines of are you using variables and values > that happen to share the same naming, e.g. "$dir" and "dir" which makes a > mess much easier? And this is how the domain of shell differs from C or Java. Shell is happy to use the constant string "dir" instead of the variable $dir. It likely isn't what was intended. Or at least it deserves a look. -Steve
Re: Bad loop construct
On Tue, May 24, 2022 at 9:25 AM Steve Grubb wrote: > Hello, > > I am continuing to look at ShellCheck and how to map it's warnings to > CWE's. > I'm looking at SC2043 - This loop will only ever run once for a constant > value. > > https://www.shellcheck.net/wiki/SC2043 > > An example might be: > > dir=$(ls $HOME) > for i in dir > do > echo $i > done > > which outputs "dir" because it's missing the "$" in the for statement. > > One of my thoughts is this could be CWE-606: Unchecked Input for Loop > Condition. It talks about unchecked inputs causing excessive looping. What > about wrong input for loop conditional causing no iteration? > > Another thought is this could be CWE-670: Always-Incorrect Control Flow > Implementation. (But looking at that, I would have expected other bad loop > nodes such as CWE-835: Loop with Unreachable Exit Condition.) > > Is there a better fit? Shell scripting problems really are a hard to match > to > a CWE because it's problems are similar but very different than C. > Hmm. What about the case where the dev puts in the values, e.g.: for VARIABLE in file1 file2 file3 do command1 on $VARIABLE done which of course could be applied for a single thing as well (to afford future flexibility/etc): for VARIABLE in file1 do command1 on $VARIABLE done and then the question is "did the programmer mean to have a variable called "dir" and an actual instance of a file or directory or whatever called "dir"? Probably not but maybe yes? Maybe a more generic along the lines of are you using variables and values that happen to share the same naming, e.g. "$dir" and "dir" which makes a mess much easier? > > Best Regards, > -Steve > > -- Kurt Seifried (He/Him) k...@seifried.org
