Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-3410 #52

Closed
fdgnneig opened this issue Feb 14, 2021 · 8 comments
Closed

CVE-2021-3410 #52

fdgnneig opened this issue Feb 14, 2021 · 8 comments

Comments

@fdgnneig
Copy link

Following vulnerability has been reported to Red Hat issue tracker:

https://bugzilla.redhat.com/show_bug.cgi?id=1928437

@jmoellers
Copy link

jmoellers commented Feb 25, 2021

Problem is that there is a string
CSI n f
where "n" is HUGE (48888888888)!
The canvas created has dimensions 0x0. What should happen if I move the cursor outside this canvas? Should it grow or should it just wrap-around?

@jmoellers
Copy link

The value (48888888888) doesn't fit into an "int" (which has 32 bits, even on a 64 bit architecture!), so it is truncated to 1644248632 but even then, the sizes (width * height) exceed 32 bits, so some calculations' results may be truncated, while others may not be.

  1. arguments of certain escape sequences should be checked that they do not exceed certain ranges
  2. either a number of calculations (escpecially those involving width and heights) should be performed with 64 bit (unsigned long int or uint64_t) or they should be checked for overflow and rejected (ERANGE?)!

@samhocevar
Copy link
Contributor

Thanks for reporting this. I went for EOVERFLOW which seemed appropriate.

@jmoellers
Copy link

This doesn't compile as "new_size" has already been declared at the start of the function.

@samhocevar
Copy link
Contributor

Sorry, I forgot to amend a faulty commit. I force-pushed, apologies if this causes inconveniences.

@jmoellers
Copy link

jmoellers commented Feb 26, 2021

Strange ... it still crashes:
Program received signal SIGFPE, Arithmetic exception.
caca_resize (cv=cv@entry=0x6026c0, width=width@entry=0, height=height@entry=0) at canvas.c:383
383 if (new_size / width != height)

Ahem ... width = 0 ... this creates a black hole ;-) (albeit a very small one as new_size is also 0).

@jmoellers
Copy link

Works with the added check "if (width != 0 && new_size / width != height)".

@samhocevar
Copy link
Contributor

Haha, well at least a division by zero is less severe than an out of bounds memory access!

Fixed properly in e4968ba, and added unit tests so that it doesn’t happen again.

bob-beck pushed a commit to openbsd/ports that referenced this issue Nov 28, 2021
Changelog:
https://github.com/cacalabs/libcaca/releases/tag/v0.99.beta20

There are some CVE fixes listed there (e.g., buffer overflow, illegal
WRITE access, illegal READ access). Here is one:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3410
cacalabs/libcaca#52

This update:
- Moves MASTER_SITES to github
  (http://caca.zoy.org/browser/libcaca/trunk/README)
- Defines V and PKGNAME substitution
- Bumps major because of removed symbols. libcaca is moving away from
  using libcucul.
- Disable building ruby subdirectory in Makefile.in patch to be
  consistent with --disable-ruby.
- Remove -g -O2 and bash-ism =~ in patch-configure. bash-ism throws
  an error otherwise. Reorder comments while here.

Feedback, tests and OK thfr@
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants