3 ms·

Not sure where 248 hours came from. 38 terabytes = 304 terabits. 304 terabits / 1 gigabit/second = 304,000 seconds 304,000 seconds =~ 84 hours. Add 20% for

by mlyle 3y ago

Not sure where 248 hours came from. 38 terabytes = 304 terabits. 304 terabits / 1 gigabit/second = 304,000 seconds 304,000 seconds =~ 84 hours. Add 20% for not pegging the line the whole time and the limits of 1gbps ethernet, and perhaps 100 hours is reasonable.

permo-w 3y ago
my mistake, I swapped the 38tb and 112tb from parent comment whatever the download size is, you're bottlenecked by the remote server's up speed
- mlyle 3y ago
  If the "remote server" is Azure, the target throughput is 0.5gbps ... for each large blob (of which this leak includes many). It seems pretty likely you'll be able to download at a few gigabits per second if your local connectivity allows.
  - permo-w 3y ago
    that's a big if
    - mlyle 3y ago
      We're talking about exfiltrating data from incorrect permissions on Azure, so it's not an if. It's a given for the situation in the article that we're discussing in this thread.
      - permo-w 3y ago
        that's not quite true. the article discusses a transfer from Azure to Github. The article does not say where the files are currently hosted, besides being publicly available on Github. It's probably Azure, but it could easily also be whatever Github use
        mlyle 3y ago
        No, that is an incorrect reading of the article. A GitHub repository mentioned an Azure storage URL; that storage service was incorrectly configured-- exposing many sensitive blobs besides the one that was intended to be shared via the URL. The URL was: "https\://robustnessws4285631339.blob.core.windows.net/public-models/robust_imagenet/resnet18_l2_eps3.ckpt?sv=2020-08-04&ss=bfqt&srt=sco&sp=rwdlacupitfx&se=2051-10-06T07:09:59Z&st=2021-10-05T23:09:59Z&spr=https,http&sig=U69sEOSMlliobiw8OgiZpLTaYyOA5yt5pHHH5%2FKUYgI%3D" (Backslash added to prevent HN from detecting it as an URL and shortening). The issue was that "sig=U69s...." token gave access to far more than the researchers intended to share.
        permo-w 3y ago
        I stand corrected

by mlyle 3y ago

permo-w 3y ago

my mistake, I swapped the 38tb and 112tb from parent comment whatever the download size is, you're bottlenecked by the remote server's up speed

mlyle 3y ago
If the "remote server" is Azure, the target throughput is 0.5gbps ... for each large blob (of which this leak includes many). It seems pretty likely you'll be able to download at a few gigabits per second if your local connectivity allows.
- permo-w 3y ago
  that's a big if
  - mlyle 3y ago
    We're talking about exfiltrating data from incorrect permissions on Azure, so it's not an if. It's a given for the situation in the article that we're discussing in this thread.
    - permo-w 3y ago
      that's not quite true. the article discusses a transfer from Azure to Github. The article does not say where the files are currently hosted, besides being publicly available on Github. It's probably Azure, but it could easily also be whatever Github use
      - mlyle 3y ago
        No, that is an incorrect reading of the article. A GitHub repository mentioned an Azure storage URL; that storage service was incorrectly configured-- exposing many sensitive blobs besides the one that was intended to be shared via the URL. The URL was: "https\://robustnessws4285631339.blob.core.windows.net/public-models/robust_imagenet/resnet18_l2_eps3.ckpt?sv=2020-08-04&ss=bfqt&srt=sco&sp=rwdlacupitfx&se=2051-10-06T07:09:59Z&st=2021-10-05T23:09:59Z&spr=https,http&sig=U69sEOSMlliobiw8OgiZpLTaYyOA5yt5pHHH5%2FKUYgI%3D" (Backslash added to prevent HN from detecting it as an URL and shortening). The issue was that "sig=U69s...." token gave access to far more than the researchers intended to share.
        permo-w 3y ago
        I stand corrected