Disclaimer: This is a user generated content submitted by a member of the WriteUpCafe Community. The views and writings here reflect that of the author and not of WriteUpCafe. If you have any complaints regarding this post kindly report it to us.

There is a serious networking vulnerability in netmask, an npm library that numerous applications use to parse CIDR blocks and IPv4 addresses or compare those. The issue relates to netmask’s component with more than 3 million downloads a week on npm.

The bug in netmask results in that library seeing another IP when it parses an IPv4 address that has a leading zero. That happens because of incorrect input validations.

Leading Zero Modifies The Internet Protocol Address

Many security researchers have revealed a fault in the well-known netmask library. That vulnerability concerns the way in which netmask manages mixed-format internet protocol addresses, or the addresses with leading zeroes.

It is possible to present an internet protocol address in various formats, which include integer and hexadecimal. Anyhow, the most prevalent IPv4 resources are shown in decimal formats.

Imagine that you have a decimal IP address such as this: 127.0.0.1, the widely-known localhost address. If you add a 0 at the start of it, then should an app parse it in the new form, as the address without that prefix or another one? Type it in your Google Chrome address bar, and the browser will treat it in the form of an octal IP address. Press the Enter key after typing it, and the address will change to 87.0.0.1, its decimal version. That is how almost every application should handle such an ambiguous IP address.

While 127.0.0.1 represents the usual address for loopback traffic, its vague representation turns it into a public internet protocol address that leads to another host. However, when it comes to netmask, there would be stripping and discarding of any leading zero.

As per IETF’s actual specification, an IPv4 address’s components would be interpretable as octal in the event it starts with a zero. However, netmask ignores that. Netmask will always treat those as decimal components. That means in the event of trying to prove that an internet protocol address is part of a range, then it would not be right for octal IPv4 address representation.

Fixed Version Now Out on NPM

After the responsible vulnerability reporting from the researchers concerned, netmask developer Olivier Poitrey introduced a group of fixes for that fault to Github. Introduced alongside those fixes to it were test cases that confirm that IPv4 address octets with zero at the start are regarded as octal numbers.

While one fix for the vulnerability with an identifier was introduced in netmask 2.0.0 on npm, researcher RyotaK soon regarded the fixes as incomplete.

Therefore, another identifier was assigned to the vulnerability more recently, with a different fix introduced into netmask 2.0.1.

close

Log In

Or with username:

Forgot password?

Don't have an account? Register

Forgot password?

Enter your account data and we will send you a link to reset your password.

Your password reset link appears to be invalid or expired.

Log in

Privacy Policy

Add to Collection

No Collections

Here you'll find all collections you've created before.

Login