Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
Hi Amul, Am Thu, Jun 16, 2022 at 12:16:09PM + schrieb Shah, Amul: > Thanks for explaining that! I was very worried that the reproducible > builds would fail the version. I guess you were worried since Salsa-CI was informing you about this. It was actually no change to the situation before ... except that we recently switched on Salsa-CI and so you became aware of the issue which existed all the time before. > Did I do the right things to properly close > the two bugs logged against fis-gtm? Yes. > We have another release coming out by the end of the month. I > should have that one uploaded sooner than later. Please reconsider the "add any minor version bump leads to a new binary file name" strategy. This means that fis-gtm always needs to pass the Debian new queue which always means that there is a hardly predictable delay when the package will reach the distribution. > thanks, Thanks to you as well Andreas. > Amul > > From: Andreas Tille > Date: Thursday, 06 16, 2022 at 05:23 AM > To: Shah, Amul > Cc: Neil Williams , 1009...@bugs.debian.org > <1009...@bugs.debian.org> > Subject: Re: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm > Hi Amul, > > Am Wed, Jun 15, 2022 at 01:50:32PM + schrieb Shah, Amul: > > Hi Andreas and Neil, > > I pushed my changes (for real this time) > > Thanks for pushing. I confirm I have uploaded the package to NEW (due > to new binary package name. > > > and the CI/CD pipeline reported a failure for reproducibility > > (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fmed-team%2Ffis-gtm%2F-%2Fjobs%2F2874740data=05%7C01%7Camul.shah%40fisglobal.com%7C6b002e9869384d6cadd308da4f79e086%7Ce3ff91d834c84b15a0b418910a6ac575%7C0%7C0%7C637909682140179197%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7Csdata=khmOXK3qZrSw%2BLbzR6AcHQN%2FvmGdAH5KAyB01DoD1fI%3Dreserved=0). > > I’m not sure what to do with this failure because GT.M generates output > > files in the build which modifies time stamps and what not. I’m reading the > > reprotest man page. Do either of you have any advice? For example, things I > > should not do. > > Reproducible builds can be a bit complex. I admit I *personally* tend > to ignore those issues and wait until reproducibility team might develop > a patch since they have way more experience in this field. Usually its > a consequence of the upstream build system, for instance like adding the > time stamp of the build. This should rather be replaced by the time > stamp of the debian/changelog for instance. > > Since reproducibility is not a critical issue for a package (but for > sure nice to have!) and if you have no real idea what to do its probably > fine as it is now. > > Kind regards > > Andreas. > > > Thanks, > > Amul > > > > From: Shah, Amul > > Date: Thursday, 06 09, 2022 at 04:53 PM > > To: Neil Williams , Andreas Tille > > Cc: 1009...@bugs.debian.org <1009...@bugs.debian.org> > > Subject: Re: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm > > Hi Andreas and Neil, > > Thanks for you input and patience. I pushed FIS GT.M V7.0-002 which > > includes the fixes for the CVEs listed in Bug#1009900. That was easier than > > back porting the fixes. > > > > Thanks, > > Amul > > > > On 04/21/22, 02:51 AM, "Neil Williams" wrote: > > On Wed, 20 Apr 2022 19:55:02 + > > "Shah, Amul" mailto:amul.s...@fisglobal.com>> > > wrote: > > > > > Hi Andreas, > > > In FIS's opinion, the CVE references are not actionable. > > > > (The usual term would be "exploitable".) I understand that, the CVEs > > arose from fuzz testing, so represent weaknesses, not active attacks. > > > > > One must > > > have host access and the ability to modify application source files. > > > Those users are typically database/systems administrators or a MUMPS > > > application developer. We expect that only privileged users have > > > direct access to the host with the application gating access to > > > external users. By itself, GT.M does not confer any extra privileges. > > > > > > How long we have to address these CVEs? > > > > I did not set an RC severity, I chose 'important' on the basis of the > > description in the upstream issue. There is no specific time limit for > > these CVEs - the vulnerabilities are already public, not embargoed > > until a set date. The highest severities are reserved for remotely > > exploitable CVEs. > > > > For unstable, the bes
Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
Hi Amul, Am Wed, Jun 15, 2022 at 01:50:32PM + schrieb Shah, Amul: > Hi Andreas and Neil, > I pushed my changes (for real this time) Thanks for pushing. I confirm I have uploaded the package to NEW (due to new binary package name. > and the CI/CD pipeline reported a failure for reproducibility > (https://salsa.debian.org/med-team/fis-gtm/-/jobs/2874740). I’m not sure what > to do with this failure because GT.M generates output files in the build > which modifies time stamps and what not. I’m reading the reprotest man page. > Do either of you have any advice? For example, things I should not do. Reproducible builds can be a bit complex. I admit I *personally* tend to ignore those issues and wait until reproducibility team might develop a patch since they have way more experience in this field. Usually its a consequence of the upstream build system, for instance like adding the time stamp of the build. This should rather be replaced by the time stamp of the debian/changelog for instance. Since reproducibility is not a critical issue for a package (but for sure nice to have!) and if you have no real idea what to do its probably fine as it is now. Kind regards Andreas. > Thanks, > Amul > > From: Shah, Amul > Date: Thursday, 06 09, 2022 at 04:53 PM > To: Neil Williams , Andreas Tille > Cc: 1009...@bugs.debian.org <1009...@bugs.debian.org> > Subject: Re: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm > Hi Andreas and Neil, > Thanks for you input and patience. I pushed FIS GT.M V7.0-002 which includes > the fixes for the CVEs listed in Bug#1009900. That was easier than back > porting the fixes. > > Thanks, > Amul > > On 04/21/22, 02:51 AM, "Neil Williams" wrote: > On Wed, 20 Apr 2022 19:55:02 + > "Shah, Amul" mailto:amul.s...@fisglobal.com>> wrote: > > > Hi Andreas, > > In FIS's opinion, the CVE references are not actionable. > > (The usual term would be "exploitable".) I understand that, the CVEs > arose from fuzz testing, so represent weaknesses, not active attacks. > > > One must > > have host access and the ability to modify application source files. > > Those users are typically database/systems administrators or a MUMPS > > application developer. We expect that only privileged users have > > direct access to the host with the application gating access to > > external users. By itself, GT.M does not confer any extra privileges. > > > > How long we have to address these CVEs? > > I did not set an RC severity, I chose 'important' on the basis of the > description in the upstream issue. There is no specific time limit for > these CVEs - the vulnerabilities are already public, not embargoed > until a set date. The highest severities are reserved for remotely > exploitable CVEs. > > For unstable, the best fix would seem to be a new upstream release. > There are multiple CVEs, some CVEs reference multiple commits. > > > If immediate, I can > > back-patch the specific fixes that address the CVEs. I say back patch > > because V6.3-014 was the last V6 version with a V6 block format > > database. The current V7 GT.M versions do not have an upgrade path to > > the V7 block format. We do not want to release a GT.M version to > > debmed without such an upgrade feature. If there is time, then we are > > working a V7 version with the V6 to V7 block upgrade capability and > > would like to release that. > > Seems sensible. > > > > > > Thanks, > > Amul > > > > -----Original Message- > > From: Andreas Tille mailto:andr...@an3as.eu>> > > Sent: Wednesday, April 20, 2022 3:00 PM > > To: Neil Williams mailto:codeh...@debian.org>>; > > 1009...@bugs.debian.org<mailto:1009...@bugs.debian.org>; > > Shah, Amul mailto:amul.s...@fisglobal.com>> > > Subject: Re: Bug#1009900: > > fis-gtm: Multiple CVEs in fis-gtm > > > > Hi Amul, > > > > I guess a new upstream version will fix this. Are you able to prepare > > the latest version? > > > > Kind regards > > > >Andreas. > > > > Am Wed, Apr 20, 2022 at 11:13:31AM +0100 schrieb Neil Williams: > > > Source: fis-gtm > > > Version: 6.3-014-3 > > > Severity: important > > > Tags: security > > > X-Debbugs-Cc: codeh...@debian.org<mailto:codeh...@debian.org>, Debian > > > Security Team > > > mailto:t...@security.debian.org>> > > > > > > Hi, > > > > > > The following vulnerabilities were published for fis-gtm. > > > > > > CVE-2021-44492[0]: > > > | An issue w
Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
Hi Amul, Am Thu, Jun 09, 2022 at 08:53:06PM + schrieb Shah, Amul: > Thanks for you input and patience. I pushed FIS GT.M V7.0-002 which includes > the fixes for the CVEs listed in Bug#1009900. That was easier than back > porting the fixes. Thanks a lot for your work, It seems you did not yet pushed your changes, thought. Kind regards Andreas. > Thanks, > Amul > > On 04/21/22, 02:51 AM, "Neil Williams" wrote: > On Wed, 20 Apr 2022 19:55:02 + > "Shah, Amul" mailto:amul.s...@fisglobal.com>> wrote: > > > Hi Andreas, > > In FIS's opinion, the CVE references are not actionable. > > (The usual term would be "exploitable".) I understand that, the CVEs > arose from fuzz testing, so represent weaknesses, not active attacks. > > > One must > > have host access and the ability to modify application source files. > > Those users are typically database/systems administrators or a MUMPS > > application developer. We expect that only privileged users have > > direct access to the host with the application gating access to > > external users. By itself, GT.M does not confer any extra privileges. > > > > How long we have to address these CVEs? > > I did not set an RC severity, I chose 'important' on the basis of the > description in the upstream issue. There is no specific time limit for > these CVEs - the vulnerabilities are already public, not embargoed > until a set date. The highest severities are reserved for remotely > exploitable CVEs. > > For unstable, the best fix would seem to be a new upstream release. > There are multiple CVEs, some CVEs reference multiple commits. > > > If immediate, I can > > back-patch the specific fixes that address the CVEs. I say back patch > > because V6.3-014 was the last V6 version with a V6 block format > > database. The current V7 GT.M versions do not have an upgrade path to > > the V7 block format. We do not want to release a GT.M version to > > debmed without such an upgrade feature. If there is time, then we are > > working a V7 version with the V6 to V7 block upgrade capability and > > would like to release that. > > Seems sensible. > > > > > > Thanks, > > Amul > > > > -Original Message- > > From: Andreas Tille mailto:andr...@an3as.eu>> > > Sent: Wednesday, April 20, 2022 3:00 PM > > To: Neil Williams mailto:codeh...@debian.org>>; > > 1009...@bugs.debian.org<mailto:1009...@bugs.debian.org>; > > Shah, Amul mailto:amul.s...@fisglobal.com>> > > Subject: Re: Bug#1009900: > > fis-gtm: Multiple CVEs in fis-gtm > > > > Hi Amul, > > > > I guess a new upstream version will fix this. Are you able to prepare > > the latest version? > > > > Kind regards > > > >Andreas. > > > > Am Wed, Apr 20, 2022 at 11:13:31AM +0100 schrieb Neil Williams: > > > Source: fis-gtm > > > Version: 6.3-014-3 > > > Severity: important > > > Tags: security > > > X-Debbugs-Cc: codeh...@debian.org<mailto:codeh...@debian.org>, Debian > > > Security Team > > > mailto:t...@security.debian.org>> > > > > > > Hi, > > > > > > The following vulnerabilities were published for fis-gtm. > > > > > > CVE-2021-44492[0]: > > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and > > > FIS | GT.M through V7.0-000. Using crafted input, attackers can > > > cause a type | to be incorrectly initialized in the function f_incr > > > in | sr_port/f_incr.c and cause a crash due to a NULL pointer > > > dereference. > > > > > > > > > CVE-2021-44493[1]: > > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and > > > FIS | GT.M through V7.0-000. Using crafted input, an attacker can > > > cause a | call to $Extract to force an signed integer holding the > > > size of a | buffer to take on a large negative number, which is > > > then used as the | length of a memcpy call that occurs on the > > > stack, causing a buffer | overflow. > > > > > > > > > CVE-2021-44494[2]: > > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and > > > FIS | GT.M through V7.0-000. Using crafted input, an attacker can > > > cause | calls to ZRead to crash due to a NULL pointer dereference. > > > > > > > > > CVE-2021-44495[3]: > > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and > > > FIS | GT.M through V7.0-000
Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
Hi Amul, in addition to Neil's answer I have the following remarks: Am Wed, Apr 20, 2022 at 07:55:02PM + schrieb Shah, Amul: > Hi Andreas, > In FIS's opinion, the CVE references are not actionable. One must have host > access and the ability to modify application source files. Those users are > typically database/systems administrators or a MUMPS application developer. > We expect that only privileged users have direct access to the host with the > application gating access to external users. By itself, GT.M does not confer > any extra privileges. > > How long we have to address these CVEs? If immediate, I can back-patch the > specific fixes that address the CVEs. I say back patch because V6.3-014 was > the last V6 version with a V6 block format database. I think if this will be the latest V6 version that should be released to the users than it makes sense to backport the fixes. > The current V7 GT.M versions do not have an upgrade path to the V7 block > format. We do not want to release a GT.M version to debmed without such an > upgrade feature. If there is time, then we are working a V7 version with the > V6 to V7 block upgrade capability and would like to release that. I noticed that there is V7 and I think we should work on this until end of summer. It has to pass new queue and migrate to testing until end of the year if it should be part of the next stable release. Kind regards Andreas. -- http://fam-tille.de
Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
On Wed, 20 Apr 2022 19:55:02 + "Shah, Amul" wrote: > Hi Andreas, > In FIS's opinion, the CVE references are not actionable. (The usual term would be "exploitable".) I understand that, the CVEs arose from fuzz testing, so represent weaknesses, not active attacks. > One must > have host access and the ability to modify application source files. > Those users are typically database/systems administrators or a MUMPS > application developer. We expect that only privileged users have > direct access to the host with the application gating access to > external users. By itself, GT.M does not confer any extra privileges. > > How long we have to address these CVEs? I did not set an RC severity, I chose 'important' on the basis of the description in the upstream issue. There is no specific time limit for these CVEs - the vulnerabilities are already public, not embargoed until a set date. The highest severities are reserved for remotely exploitable CVEs. For unstable, the best fix would seem to be a new upstream release. There are multiple CVEs, some CVEs reference multiple commits. > If immediate, I can > back-patch the specific fixes that address the CVEs. I say back patch > because V6.3-014 was the last V6 version with a V6 block format > database. The current V7 GT.M versions do not have an upgrade path to > the V7 block format. We do not want to release a GT.M version to > debmed without such an upgrade feature. If there is time, then we are > working a V7 version with the V6 to V7 block upgrade capability and > would like to release that. Seems sensible. > > Thanks, > Amul > > -Original Message- > From: Andreas Tille > Sent: Wednesday, April 20, 2022 3:00 PM > To: Neil Williams ; 1009...@bugs.debian.org; > Shah, Amul Subject: Re: Bug#1009900: > fis-gtm: Multiple CVEs in fis-gtm > > Hi Amul, > > I guess a new upstream version will fix this. Are you able to prepare > the latest version? > > Kind regards > >Andreas. > > Am Wed, Apr 20, 2022 at 11:13:31AM +0100 schrieb Neil Williams: > > Source: fis-gtm > > Version: 6.3-014-3 > > Severity: important > > Tags: security > > X-Debbugs-Cc: codeh...@debian.org, Debian Security Team > > > > > > Hi, > > > > The following vulnerabilities were published for fis-gtm. > > > > CVE-2021-44492[0]: > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and > > FIS | GT.M through V7.0-000. Using crafted input, attackers can > > cause a type | to be incorrectly initialized in the function f_incr > > in | sr_port/f_incr.c and cause a crash due to a NULL pointer > > dereference. > > > > > > CVE-2021-44493[1]: > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and > > FIS | GT.M through V7.0-000. Using crafted input, an attacker can > > cause a | call to $Extract to force an signed integer holding the > > size of a | buffer to take on a large negative number, which is > > then used as the | length of a memcpy call that occurs on the > > stack, causing a buffer | overflow. > > > > > > CVE-2021-44494[2]: > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and > > FIS | GT.M through V7.0-000. Using crafted input, an attacker can > > cause | calls to ZRead to crash due to a NULL pointer dereference. > > > > > > CVE-2021-44495[3]: > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and > > FIS | GT.M through V7.0-000. Using crafted input, an attacker can > > cause a | NULL pointer dereference after calls to ZPrint. > > > > > > CVE-2021-44496[4]: > > | An issue was discovered in FIS GT.M through V7.0-000 (related to > > the | YottaDB code base). Using crafted input, an attacker can > > control the | size variable and buffer that is passed to a call to > > memcpy. An | attacker can use this to overwrite key data structures > > and gain | control of the flow of execution. > > > > > > CVE-2021-44497[5]: > > | An issue was discovered in FIS GT.M through V7.0-000 (related to > > the | YottaDB code base). Using crafted input, can cause the bounds > > of a for | loop to be miscalculated, which leads to a use after > > free condition a | pointer is pushed into previously free memory by > > the loop. > > > > > > CVE-2021-44498[6]: > > | An issue was discovered in FIS GT.M through V7.0-000 (related to > > the | YottaDB code base). Using crafted input, attackers can cause > > a type to | be incorrectly initialized in the function f_incr in > > sr_port/f_incr.c | and cause a crash due to a NULL point
Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
Hi Amul, I guess a new upstream version will fix this. Are you able to prepare the latest version? Kind regards Andreas. Am Wed, Apr 20, 2022 at 11:13:31AM +0100 schrieb Neil Williams: > Source: fis-gtm > Version: 6.3-014-3 > Severity: important > Tags: security > X-Debbugs-Cc: codeh...@debian.org, Debian Security Team > > > Hi, > > The following vulnerabilities were published for fis-gtm. > > CVE-2021-44492[0]: > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS > | GT.M through V7.0-000. Using crafted input, attackers can cause a type > | to be incorrectly initialized in the function f_incr in > | sr_port/f_incr.c and cause a crash due to a NULL pointer dereference. > > > CVE-2021-44493[1]: > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS > | GT.M through V7.0-000. Using crafted input, an attacker can cause a > | call to $Extract to force an signed integer holding the size of a > | buffer to take on a large negative number, which is then used as the > | length of a memcpy call that occurs on the stack, causing a buffer > | overflow. > > > CVE-2021-44494[2]: > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS > | GT.M through V7.0-000. Using crafted input, an attacker can cause > | calls to ZRead to crash due to a NULL pointer dereference. > > > CVE-2021-44495[3]: > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS > | GT.M through V7.0-000. Using crafted input, an attacker can cause a > | NULL pointer dereference after calls to ZPrint. > > > CVE-2021-44496[4]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). Using crafted input, an attacker can control the > | size variable and buffer that is passed to a call to memcpy. An > | attacker can use this to overwrite key data structures and gain > | control of the flow of execution. > > > CVE-2021-44497[5]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). Using crafted input, can cause the bounds of a for > | loop to be miscalculated, which leads to a use after free condition a > | pointer is pushed into previously free memory by the loop. > > > CVE-2021-44498[6]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). Using crafted input, attackers can cause a type to > | be incorrectly initialized in the function f_incr in sr_port/f_incr.c > | and cause a crash due to a NULL pointer dereference. > > > CVE-2021-44499[7]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). Using crafted input, an attacker can cause a call > | to $Extract to force an signed integer holding the size of a buffer to > | take on a large negative number, which is then used as the length of a > | memcpy call that occurs on the stack, causing a buffer overflow. > > > CVE-2021-44500[8]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). A lack of input validation in calls to eb_div in > | sr_port/eb_muldiv.c allows attackers to crash the application by > | performing a divide by zero. > > > CVE-2021-44501[9]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). Using crafted input, an attacker can cause calls > | to ZRead to crash due to a NULL pointer dereference. > > > CVE-2021-44502[10]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). Using crafted input, an attacker can control the > | size of a memset that occurs in calls to util_format in > | sr_unix/util_output.c. > > > CVE-2021-44503[11]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). Using crafted input, an attacker can cause a call > | to va_arg on an empty variadic parameter list, most likely causing a > | memory segmentation fault. > > > CVE-2021-44504[12]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). Using crafted input, an attacker can cause a size > | variable, stored as an signed int, to equal an extremely large value, > | which is interpreted as a negative value during a check. This value is > | then used in a memcpy call on the stack, causing a memory segmentation > | fault. > > > CVE-2021-44505[13]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). Using crafted input, an attacker can cause a NULL > | pointer dereference after calls to ZPrint. > > > CVE-2021-44506[14]: > | An issue was discovered in FIS GT.M through V7.0-000 (related to the > | YottaDB code base). A lack of input validation in calls to do_verify > | in sr_unix/do_verify.c allows attackers to attempt to jump to a NULL > | pointer by corrupting a function pointer. > > > CVE-2021-44507[15]: > | An issue was discovered in FIS GT.M through V7.0-000 (related
Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
Source: fis-gtm Version: 6.3-014-3 Severity: important Tags: security X-Debbugs-Cc: codeh...@debian.org, Debian Security Team Hi, The following vulnerabilities were published for fis-gtm. CVE-2021-44492[0]: | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS | GT.M through V7.0-000. Using crafted input, attackers can cause a type | to be incorrectly initialized in the function f_incr in | sr_port/f_incr.c and cause a crash due to a NULL pointer dereference. CVE-2021-44493[1]: | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS | GT.M through V7.0-000. Using crafted input, an attacker can cause a | call to $Extract to force an signed integer holding the size of a | buffer to take on a large negative number, which is then used as the | length of a memcpy call that occurs on the stack, causing a buffer | overflow. CVE-2021-44494[2]: | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS | GT.M through V7.0-000. Using crafted input, an attacker can cause | calls to ZRead to crash due to a NULL pointer dereference. CVE-2021-44495[3]: | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS | GT.M through V7.0-000. Using crafted input, an attacker can cause a | NULL pointer dereference after calls to ZPrint. CVE-2021-44496[4]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). Using crafted input, an attacker can control the | size variable and buffer that is passed to a call to memcpy. An | attacker can use this to overwrite key data structures and gain | control of the flow of execution. CVE-2021-44497[5]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). Using crafted input, can cause the bounds of a for | loop to be miscalculated, which leads to a use after free condition a | pointer is pushed into previously free memory by the loop. CVE-2021-44498[6]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). Using crafted input, attackers can cause a type to | be incorrectly initialized in the function f_incr in sr_port/f_incr.c | and cause a crash due to a NULL pointer dereference. CVE-2021-44499[7]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). Using crafted input, an attacker can cause a call | to $Extract to force an signed integer holding the size of a buffer to | take on a large negative number, which is then used as the length of a | memcpy call that occurs on the stack, causing a buffer overflow. CVE-2021-44500[8]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). A lack of input validation in calls to eb_div in | sr_port/eb_muldiv.c allows attackers to crash the application by | performing a divide by zero. CVE-2021-44501[9]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). Using crafted input, an attacker can cause calls | to ZRead to crash due to a NULL pointer dereference. CVE-2021-44502[10]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). Using crafted input, an attacker can control the | size of a memset that occurs in calls to util_format in | sr_unix/util_output.c. CVE-2021-44503[11]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). Using crafted input, an attacker can cause a call | to va_arg on an empty variadic parameter list, most likely causing a | memory segmentation fault. CVE-2021-44504[12]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). Using crafted input, an attacker can cause a size | variable, stored as an signed int, to equal an extremely large value, | which is interpreted as a negative value during a check. This value is | then used in a memcpy call on the stack, causing a memory segmentation | fault. CVE-2021-44505[13]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). Using crafted input, an attacker can cause a NULL | pointer dereference after calls to ZPrint. CVE-2021-44506[14]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). A lack of input validation in calls to do_verify | in sr_unix/do_verify.c allows attackers to attempt to jump to a NULL | pointer by corrupting a function pointer. CVE-2021-44507[15]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). A lack of parameter validation in calls to memcpy | in str_tok in sr_unix/ztimeoutroutines.c allows attackers to attempt | to read from a NULL pointer. CVE-2021-44508[16]: | An issue was discovered in FIS GT.M through V7.0-000 (related to the | YottaDB code base). A lack of NULL checks in calls to ious_open in | sr_unix/ious_open.c allows attackers to crash the application by | dereferencing a NULL
