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

Fix panic due to invalid schedule string #365

Closed
wants to merge 1 commit into from
Closed

Fix panic due to invalid schedule string #365

wants to merge 1 commit into from

Conversation

ericcornelissen
Copy link

Fix a bug where cron panics if the schedule string ("spec") has a particular format, namely exactly "TZ=" or "CRON_TZ=". If this string is user controlled that user may be able to cause a panic and thereby exit the program that is using cron. Alternatively, if the string is constructed dynamically by the program and there is a mistake in that logic, the program would panic unexpectedly.

The solution I propose is simply to check against the condition that causes cron to panic. There are alternative solution, e.g.:

  • Using more complex logic (using e.g. regexp) to detect the "(CRON_)TZ" syntax.
  • Updating parsing logic so that the "provided bad location" error is returned. I opted away from this as I figured it might be useful to distinguish these two scenarios.

I also added some tests for these strings to ensure they're properly accounted for in the future.

Disclosure: I found this bug using https://github.com/dvyukov/go-fuzz and did not encounter any other parsing issues.

Fix a bug where cron panics if the schedule string ("spec") has a
particular format, namely "TZ=" or "CRON_TZ=". If this is string is user
controlled that user may be able to panic and thereby exit the program
using cron. Alternatively, if the string is constructed dynamically by
the program and there is a mistake in that logic, it would panic
unexpectedly.

The solution I propose is simply to check against the condition that
causes cron to panic. There are alternative solution, e.g.:
- Using  more complex logic (using e.g. regexp) to detect the
  "TZ"-syntax.
- Updating parsing logic so that the "provided bad location" error is
  returned. I opted away from this as I figured it might be useful to
  distinguish these two scenarios.

Disclose: I found this bug using https://github.com/dvyukov/go-fuzz and
did not encounter any other parsing issues.
@ericcornelissen ericcornelissen closed this by deleting the head repository Sep 22, 2022
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

Successfully merging this pull request may close these issues.

1 participant