Skip to main content

Slashdot: IPv4 Parsing Flaw In NPM Netmask Could Affect 270,000 Apps

IPv4 Parsing Flaw In NPM Netmask Could Affect 270,000 Apps
Published on March 31, 2021 at 03:30PM
chicksdaddy shares a report from The Security Ledger: Independent security researchers analyzing the widely used open source component netmask have discovered security vulnerabilities that could leave more than a quarter million open source applications vulnerable to attack, according to a report released Monday, The Security Ledger reports. According to a report by the site Sick Codes, the flaws open applications that rely on netmask to a wide range of malicious attacks including Server Side Request Forgeries (SSRF) and Remote- and Local File Includes (RFI, LFI) that could enable attackers to ferry malicious code into a protected network, or siphon sensitive data out of one. Even worse, the flaws appear to stretch far beyond a single open source module, affecting a wide range of open source development languages, researchers say. Netmask is a widely used package that allows developers to evaluate whether a IP address attempting to access an application was inside or outside of a given IPv4 range. Based on an IP address submitted to netmask, the module will return true or false about whether or not the submitted IP address is in the defined "block." According to the researcher using the handle "Sick Codes," the researchers discovered that netmask had a big blind spot. Specifically: it evaluates certain IP addresses incorrectly: improperly validating so-called "octal strings" rendering IPv4 addresses that contain certain octal strings as integers. For example, the IP4 address 0177.0.0.1 should be evaluated by netmask as the private IP address 127.0.0.1, as the octal string "0177" translates to the integer "127." However, netmask evaluates it as a public IPv4 address: 177.0.0.1, simply stripping off the leading zero and reading the remaining parts of the octal string as an integer. The implications for modules that are using the vulnerable version of netmask are serious. According to Sick Codes, remote attackers can use SSRF attacks to upload malicious files from the public Internet without setting off alarms, because applications relying on netmask would treat a properly configured external IP address as an internal address. Similarly, attackers could also disguise remote IP addresses local addresses, enabling remote file inclusion (RFI) attacks that could permit web shells or malicious programs to be placed on target networks. But researchers say much more is to come. The problems identified in netmask are not unique to that module. Researchers have noted previously that textual representation of IPv4 addresses were never standardized, leading to disparities in how different but equivalent versions of IPv4 addresses (for example: octal strings) are rendered and interpreted by different applications and platforms.

Read more of this story at Slashdot.

Comments

Popular posts from this blog

Slashdot: AT&T Says Leaked Data of 70 Million People Is Not From Its Systems

AT&T Says Leaked Data of 70 Million People Is Not From Its Systems Published on March 20, 2024 at 02:15AM An anonymous reader quotes a report from BleepingComputer: AT&T says a massive trove of data impacting 71 million people did not originate from its systems after a hacker leaked it on a cybercrime forum and claimed it was stolen in a 2021 breach of the company. While BleepingComputer has not been able to confirm the legitimacy of all the data in the database, we have confirmed some of the entries are accurate, including those whose data is not publicly accessible for scraping. The data is from an alleged 2021 AT&T data breach that a threat actor known as ShinyHunters attempted to sell on the RaidForums data theft forum for a starting price of $200,000 and incremental offers of $30,000. The hacker stated they would sell it immediately for $1 million. AT&T told BleepingComputer then that the data did not originate from them and that its systems were not breached. &q

Slashdot: AT&T, T-Mobile Prep First RedCap 5G IoT Devices

AT&T, T-Mobile Prep First RedCap 5G IoT Devices Published on October 15, 2024 at 03:20AM The first 5G Internet of Things (IoT) devices are launching soon. According to Fierce Wireless, T-Mobile plans to launch its first RedCap devices by the end of the year, while AT&T's devices are expected sometime in 2025. From the report: All of this should pave the way for higher performance 5G gadgets to make an impact in the world of IoT. RedCap, which stands for reduced capabilities, was introduced as part of the 3GPP's Release 17 5G standard, which was completed -- or frozen in 3GPP terms -- in mid-2022. The specification, which is also called NR-Light, is the first 5G-specific spec for IoT. RedCap promises to offer data transfer speeds of between 30 Mbps to 80 Mbps. The RedCap spec greatly reduces the bandwidth needed for 5G, allowing the signal to run in a 20 MHz channel rather than the 100 MHz channel required for full scale 5G communications. Read more of this story at

Slashdot: AT&T Can't Hang Up On Landline Phone Customers, California Agency Rules

AT&T Can't Hang Up On Landline Phone Customers, California Agency Rules Published on June 22, 2024 at 01:50AM An anonymous reader quotes a report from Ars Technica: The California Public Utilities Commission (CPUC) yesterday rejected AT&T's request to end its landline phone obligations. The state agency also urged AT&T to upgrade copper facilities to fiber instead of trying to shut down the outdated portions of its network. AT&T asked the state to eliminate its Carrier of Last Resort (COLR) obligation, which requires it to provide landline telephone service to any potential customer in its service territory. A CPUC administrative law judge recommended rejection of the application last month, and the commission voted to dismiss AT&T's application with prejudice on Thursday. "Our vote to dismiss AT&T's application made clear that we will protect customer access to basic telephone service... Our rules were designed to provide that assurance,