Stories with Tag IP address

• Docker limits unauthenticated pulls to 10/HR/IP from Docker Hub, from March 1

  permalink

  Posted: 2025-02-21 07:42:45

  Verbose tl;dr

  Starting March 1st, Docker Hub will implement rate limits for anonymous (unauthenticated) image pulls. Free users will be limited to 100 pulls per six hours per IP address, while authenticated free users get 200 pulls per six hours. This change aims to improve the stability and performance of Docker Hub. Paid Docker Hub subscriptions will not have pull rate limits. Users are encouraged to log in to their Docker Hub account when pulling images to avoid hitting the new limits.

  Docker Hub, the primary registry for Docker images, is implementing rate limits on image pulls for anonymous (unauthenticated) users. Starting March 1st, anonymous users will be limited to 10 pulls per six hours per IP address. This change is being implemented to ensure the stability and performance of Docker Hub for all users and to combat abuse.

  This limitation applies to all Docker clients pulling images directly from Docker Hub without authentication. This means users who access Docker Hub through a Docker desktop client or other Docker tools without logging in will be subject to these limits.

  The limits are calculated based on the IP address initiating the pull request. Therefore, multiple users sharing a single IP address, such as those behind a corporate firewall or NAT, will share the same pool of 10 pulls per six hours. Exceeding this limit will result in the pull request being denied with an error message indicating the rate limit has been reached.

  This policy change does not affect authenticated users. Users who log in to Docker Hub with their Docker ID will not be subject to these rate limits and can continue to pull images without restriction. Docker strongly encourages users to log in for uninterrupted access and to take advantage of other benefits, such as access to private repositories and automated builds.

  This new rate limit is specifically for pulls, not pushes. Pushing images to Docker Hub still requires authentication and is unaffected by this change.

  Organizations and individuals who anticipate that the anonymous pull limits will disrupt their workflows are advised to create free Docker Hub accounts and log in when pulling images. This will allow them to avoid the rate limits entirely. This is especially important for automated build processes or environments where many pulls are performed from a shared IP address.

  • docker
  • Docker Hub
  • Rate Limiting
  • Image Pulls
  • Containerization
  • DevOps
  • Security
  • Authentication
  • IP address
  • API Limits

  Summary of Comments ( 290 )
  https://news.ycombinator.com/item?id=43125089

  Verbose tl;dr

  Hacker News users discuss the implications of Docker Hub's new rate limits on unauthenticated pulls. Some express concern about the impact on CI/CD pipelines, suggesting the 100 pulls per 6 hours for authenticated free users is also too low for many use cases. Others view the change as a reasonable way for Docker to manage costs and encourage users to authenticate or use alternative registries. Several commenters share workarounds, such as using a private registry or caching images more aggressively. The discussion also touches on the broader ecosystem and the role of Docker Hub within it, with some users questioning its long-term viability given past pricing changes and policy shifts. A few users report encountering unexpected behavior with the limits, suggesting potential inconsistencies in enforcement.

  The Hacker News post discussing Docker Hub's new rate limits on unauthenticated pulls generated a significant number of comments, with many users expressing their concerns and opinions.

  Several commenters saw the move as a way for Docker to push users towards paid plans. They felt that the limits were too restrictive, especially for open-source projects and smaller developers who rely on Docker Hub for their workflows. The sentiment was that this change would disrupt their current processes and potentially force them to consider alternatives. Some users questioned the effectiveness of this strategy, suggesting it might drive users away from Docker altogether rather than towards paid subscriptions.

  A common point of discussion revolved around the impact on CI/CD pipelines. Commenters pointed out that shared CI/CD runners often use the same IP address, meaning the rate limits could be easily hit, causing builds to fail. This concern highlighted the potential for widespread disruption for projects relying on such infrastructure. Some suggested using authenticated pulls as a workaround, but others noted that this isn't always feasible or desirable, especially for open-source projects.

  The technical details of the implementation were also scrutinized. Some users questioned the choice of using IP addresses for rate limiting, arguing that it's not a reliable method due to the prevalence of shared IPs and dynamic IP allocation. This could lead to legitimate users being unfairly throttled. Alternatives like user-agent based limiting were proposed.

  There was a discussion about the potential for abuse and the motivation behind Docker's decision. Some commenters speculated that this move was aimed at combating cryptocurrency miners who might be leveraging Docker Hub's resources. Others suggested that it could be a response to excessive bandwidth usage and the associated costs.

  Some users expressed understanding for Docker's need to monetize its services, but they also emphasized the importance of a generous free tier for the health of the Docker ecosystem. The feeling was that striking a balance between monetization and community support was crucial for the long-term success of Docker.

  Finally, a few commenters offered alternative solutions and workarounds, such as setting up private registries or using different container registries altogether. This reflected a proactive approach within the community to adapt to the new limitations.

• 0-click deanonymization attack targeting Signal, Discord, other platforms

  permalink

  Posted: 2025-01-21 14:59:44

  Verbose tl;dr

  A security vulnerability, dubbed "0-click," allowed remote attackers to deanonymize users of various communication platforms, including Signal, Discord, and others, by simply sending them a message. Exploiting flaws in how these applications handled media files, specifically embedded video previews, the attacker could execute arbitrary code on the target's device without any interaction from the user. This code could then access sensitive information like the user's IP address, potentially revealing their identity. While the vulnerability affected the Electron framework underlying these apps, rather than the platforms themselves, the impact was significant as it bypassed typical security measures and allowed complete deanonymization with no user interaction. This vulnerability has since been patched.

  A newly disclosed vulnerability, dubbed the "0-click deanonymization attack," poses a significant threat to user privacy on several popular communication platforms, including Signal, Discord, and others employing WebRTC, a real-time communication technology. This attack exploits a subtle flaw in the way these platforms handle IP address leaks within WebRTC connections, allowing a malicious actor to uncover the IP address of a target user without any interaction from the target—hence the "0-click" designation.

  The exploit leverages Session Traversal Utilities for NAT (STUN) and Interactive Connectivity Establishment (ICE) servers, integral components of WebRTC's functionality. These servers facilitate the establishment of peer-to-peer connections by assisting clients in discovering their public IP addresses and traversing network address translation (NAT) gateways. Normally, these IP addresses are exchanged between communicating parties. However, the vulnerability arises from the fact that these platforms inadvertently expose IP addresses to STUN/ICE servers even before a connection is fully established, and crucially, even if the target user declines or ignores a call.

  The attacker initiates a WebRTC connection request to the target user. Even if the target doesn't accept the call, the target's client still interacts with the STUN/ICE servers, revealing its IP address in the process. The attacker, by controlling or monitoring the STUN/ICE server, can passively intercept this communication and capture the target's IP address. This allows for deanonymization, linking the target's online identity on the platform to their real-world location and potentially revealing their true identity.

  This vulnerability is particularly insidious because it requires no action from the target user. Merely receiving a connection request, even an ignored or rejected one, is sufficient for the attack to succeed. This bypasses traditional defenses against IP address leaks, such as disabling WebRTC entirely or using VPNs, as the leakage occurs before these protective measures can effectively intervene. While VPNs might mask the true IP address, the timing correlation between the call attempt and the observed IP address on the VPN server could still provide valuable information to a determined attacker.

  The technical details of the exploit involve manipulating the JavaScript execution within the target's browser to control the flow of WebRTC negotiation and observe the STUN/ICE server interactions. The author of the disclosure emphasizes the simplicity of the attack and its broad applicability to any platform utilizing WebRTC without adequate safeguards. The potential consequences of this vulnerability are serious, ranging from targeted harassment and doxing to large-scale surveillance and privacy breaches.

  • signal
  • Discord
  • deanonymization
  • privacy
  • Security
  • Vulnerability
  • attack
  • metadata
  • 0-click
  • Exploit
  • IP address
  • online privacy
  • communication platforms
  • messaging apps

  Summary of Comments ( 294 )
  https://news.ycombinator.com/item?id=42780816

  Verbose tl;dr

  Hacker News commenters discuss the practicality and impact of the described 0-click deanonymization attack. Several express skepticism about its real-world applicability, noting the attacker needs to be on the same local network, which significantly limits its usefulness compared to other attack vectors. Some highlight the importance of the disclosure despite these limitations, as it raises awareness of potential vulnerabilities. The discussion also touches on the technical details of the exploit, with some questioning the "0-click" designation given the requirement for the target to join a group call. Others point out the responsibility of Electron, the framework used by the affected apps, for not sandboxing UDP sockets effectively, and debate the trade-offs between security and performance. A few commenters discuss potential mitigations and the broader implications for user privacy in online communication platforms.

  The Hacker News post titled "0-click deanonymization attack targeting Signal, Discord, other platforms" generated a significant discussion with a variety of comments. Several commenters focused on the technical aspects of the exploit, highlighting how seemingly innocuous features like generating link previews could be manipulated to leak IP addresses. There's a strong consensus that the core issue stems from servers fetching content from user-supplied URLs without proper safeguards.

  Some commenters questioned the "0-click" nature of the attack, arguing that a user still needs to engage with a message containing a malicious link, even if they don't explicitly click it. Others pointed out that the practicality of the attack is limited by the need for the attacker to control a server capable of logging IP addresses connecting to it.

  The discussion also touched upon the responsibility of different platforms. Some commenters argued that platforms like Signal and Discord should have implemented better protections against this type of attack, while others emphasized that the underlying issue lies with the broader ecosystem of link previews and the lack of standardized security measures.

  A few commenters provided technical insights into potential mitigations, including the use of proxy servers for fetching previews and stricter validation of URLs. The feasibility and potential downsides of these solutions were also debated.

  Some users shared anecdotal evidence of similar attacks or vulnerabilities they've encountered in the past, reinforcing the concern about the potential for abuse of link preview functionality.

  Finally, there was some discussion about the ethical implications of researching and disclosing such vulnerabilities, with opinions varying on the responsible approach to handling such sensitive information. The overall sentiment seems to be one of concern about the potential privacy implications of this attack vector and the need for a broader industry response to address the underlying issues.