SSH: Unable to marshal data #318
Comments
|
The workaround I used for this is to demote the Line 181 in 3fc8248 |
As called by grabTarget. The proximate cause for this is zmap#318 (SSH certificates with dates too large crash the process), and the fix is due to @TrueSkrillor in that same issue. The source of the error is the go standard library's time module (https://cs.opensource.google/go/go/+/master:src/time/time.go;drc=41b9d8c75e45636a153c2a31d117196a22a7fc6c;l=1317), and it points us to golang/go#4556 (comment). Essentially, time is trying to produce a RFC3339 string, and refuses to do so with a year too big. We began seeing this problem about the week of June 6, 2022, and this change fixed it for us. However, this does appear to be a global change, applying to all scanners. We aren't currently affected by this (or we would have had other uses of zgrab2 crashing with a similar error), but in the future, should we hit bad data, we won't crash, we'll just get a logged warning that we may not notice. That's both good and bad. I don't know go well. I was a bit concerned about passing what must be the nil return value back from grabTarget, into the outputQueue byte[] channel, and ultimately into the OutputResults function which wants to write it to the (buffered) output file. However, it appears that, because len(v), where v is a byte[], is 0, nothing actually happens: the empty result is swallowed.
|
It looks like the specific issue with the SSH scanner here has to do with the failure to marshal JSON Lines 68 to 72 in 48f15ef The issue arises because it looks like Lines 154 to 158 in 48f15ef The embedded unserializable Line 181 in 48f15ef |
As called by grabTarget. The proximate cause for this is #318 (SSH certificates with dates too large crash the process), and the fix is due to @TrueSkrillor in that same issue. The source of the error is the go standard library's time module (https://cs.opensource.google/go/go/+/master:src/time/time.go;drc=41b9d8c75e45636a153c2a31d117196a22a7fc6c;l=1317), and it points us to golang/go#4556 (comment). Essentially, time is trying to produce a RFC3339 string, and refuses to do so with a year too big. We began seeing this problem about the week of June 6, 2022, and this change fixed it for us. However, this does appear to be a global change, applying to all scanners. We aren't currently affected by this (or we would have had other uses of zgrab2 crashing with a similar error), but in the future, should we hit bad data, we won't crash, we'll just get a logged warning that we may not notice. That's both good and bad. I don't know go well. I was a bit concerned about passing what must be the nil return value back from grabTarget, into the outputQueue byte[] channel, and ultimately into the OutputResults function which wants to write it to the (buffered) output file. However, it appears that, because len(v), where v is a byte[], is 0, nothing actually happens: the empty result is swallowed.
|
I see there was a commit pushed for this. Did it resolve your issue @TrueSkrillor ? mentioning #355 to link it here |
|
Yup, it works as expected. |
Hey everyone,
I stumbled across a fatal error while performing an internet-wide ssh scan as part of my masters thesis resulting in premature end of the scan. After some time, zgrab2 logs the following error and quits:
FATA[10636] unable to marshal data: json: error calling MarshalJSON for type ssh.kexAlgorithm: json: error calling MarshalJSON for type ssh.PublicKey: json: error calling MarshalJSON for type time.Time: Time.MarshalJSON: year outside of range [0,9999]As the error message indicates the timestamp of the public key seems to be invalid (not within the valid range). By extending the call to the logging function I was able to isolate the list of IPs that caused this issue. As it turned out only six IPs in the entire IPv4 address space caused this issue but I will try to avoid sharing the IPs publicy due to obvious reasons.
For debugging purposes I performed a SSH handshake using OpenSSH with verbose output enabled (which was possible). See below for the captured output (I stripped the log file a little but it should still contain all necessary information):
The expiration date of the host certificate suggests that this error may be directly related to the year 2038 problem, causing an arithmetic overflow in some 32 bit signed integer.
The text was updated successfully, but these errors were encountered: