I was relatively sure that part of the problem was that the system's USB controllers could also be coopted by plugging in a bad USB device, whether the system recognized said device or not.
Then you've not read up on the issue as much as your stong opinions on it would seem to imply.
Correct me if I'm oversimplifying the problem.
I've been trying...
I'll also bet your SSDs are on SATA connections, those are 1:1 internal, you mention that yourself.
You know what else I mentioned?
Then why don't I see an issue with it when I connect 2 portable drives (bare enclosures in which I've put a couple of Samsung SSDs) via a USB hub?
Indeed, I've been trying in vain, as you clearly don't read. Mind you, these are drive I use every day for high-speed media transfer. I'm sure I don't know WTF I'm talking about, though, and the world is just bending to my will. Right?
As you've shown a complete unwillingness to actually consider that you may be wrong, or to even read the posts you're replying to, let alone the linked information (because you're likely sure it'll prove you wrong), I think we're done here. I'm sure anyone reading this will have read everything, leaving you the only one who still thinks you're right.
I didn't see any of that in the Wired story. It essentially stated: "plug it in, it infects your PC, Antivirus software is useless, and future USB devices plugged into your system can be infected". When Bruce wrote about it along with quite a few others, the evidence seems to point to a rather bad security flaw.
Well, as USB itself does not provide DMA (again, this is requested and handled at the driver level), a USB device can do absolutely nothing until the system recognizes it and starts talking to it (e.g. via a driver). You clearly didn't follow what you've read, or you'd understand that the nature of this vulnerability is that many devices don't have firmware programming disabled and can be reprogrammed to behave as other devices (in fact, you do seem to understand this, as you said "The problem lies in that USB trusts the device to be what it says it is, even if that is more than one thing", which is correct; it's equally correct that a USB device can be more than one thing, e.g. an audio device and a video device, so that's not a flaw, the flaw is in the devices being reprogrammable in the first place). Which, of course, means the devices have to be identified by the system and a driver has to exist for whatever they identify as.
Further proof that it is a device issue here, and evidence that USB devices must be "accepted" by the host before they can to anything at all, here. Not that this should be necessary, given a basic understanding of what you're talking about and a bit of logic.
The short answer to this one is I only usually have 1 set of devices that are relatively permanent for those other buses. It's not a thumbdrive that gets passed around.
That's you; Firewire is still fairly widely used in media production, and the devices using it include cameras, control boards, and DAT decks, which do get passed around. And without USB, where do you think you'd plug that thumb drive?
Drop 2 sets of file transfers through the disks on that one hub, and see what happens.
Okay, so you're doing two copy operations and are surprised when seek times slow them by more than 50%? You don't copy files on spinning disks much, do you? I do it all the time, albeit with SSDs, and have not once seen the slowdown you are talking about, so either you're full of shit, your equipment is full of shit, or you don't really know where the slowdown is coming from, but none of that is the fault of USB.
I have about 10 disks hooked up and was copying files between 3 sets (3 full speed copy operations, including 2 SSDs) with each disk capable of +100MB/s on large file sequential read/write speeds.
Which is it, 10 or 2? One, two, or three transfers? All this goalpost moging makes me think you're just full of shit.
You state that your drives can handle 100MB/s; USB3 is 5gbps (that's 640MBps), while SATA is 1.5, 3., or 6gbps (187.5, 375, or 750MB/s) depending on whether you've got SATA I, II, or III ports. On a high-end mobo like you claim to own, it's probably SATA-III, so 6gbps. That includes a fair bit of overhead, so the best you can e
Everybody had USB, I never said everybody used it. That said, I refer you to this post, with actual references, so you can see just how wrong you are. Firewire came out on 1994, by the way, on Macs, 4 years before they added USB to the iMac.
Or I just didn't pay attention to Apple in the '90s and was too lazy to look it up. As a 2000 grad, I'd say I lived through the 90's. I also tend to get my history right when it related to something I actually care about. That being said:
If they hang it in their front lawn... are you telling me it's illegal to look at it? Of course it's not legal to take,; but, then. nobody claimed it was fine to take someone's security camera because they didn't change the default password, either. Legal to view it? Well, yes, until such time that you could reasonably realize that they, perhaps, hadn't intended to make it public.
But, of course, you knew what I meant and were simply being obtuse for the sake of argument. Bravo.
There is a DMA component, a quick search reveals they haven't fixed that either yet.
You mean that drivers can determine whether they, themselves, require DMA? That's no worse than the device having DMA itself; in fact, it's damn sight better, given that Firewire device doesn't even have to identify itself, let alone have that identity accepted by the system, to gain that level of access, meanwhile a USB device must identify itself as a device whose driver required DMA, that driver must be present, and it must emulate that device well enough to fool the driver into actually talking to it; the bar is a fair bit higher with USB than DMA.
The problem lies in that USB trusts the device to be what it says it is, even if that is more than one thing.
That's all fine and dandy, the device still has to fool the driver, as well, whereas the OHCI 1394 specification (aka Firewire) allows for devices for performance reasons to bypass the operating system and access physical memory directly without any security restrictions.. In case Wikipedia isn't a strong enough source for you, here is the actual specification. A Firewire or Thunderbolt device or, as you correctly point out, ecpressCard, PCI, PCI-express (though you're really repeating yourself with that list) device doesn't even need OS or driver cooperation to be rejected by your system, it just pops on the bus and says "Let me see this RAM" and gets what it wants. Hell, it can do that repeatedly until it finds the bit of vulnerable code it's after and immediately turn around and overwrite it with an exploit. Actually, there's nothing stopping it from using that method to exploit your OS' I/O stack to allow itself to write arbitrary files on disk. All with no drivers, or authentication.
If you're worried about USB, you need to be terrified about the other busses in your system.
I was referring to WIred's story[...]... which provides the same details about the same thing (BadUSB). So, then, I was right? You were talking about BadUSB? Good.
The slow down is a direct result of the design of USB serial communications.
Then why don't I see an issue with it when I connect 2 portable drives (bare enclosures in which I've put a couple of Samsung SSDs) via a USB hub? Also, if not a hub, why did you say:
"Hook 2 devices up to a USB 3 hub, watch yourself get lower than USB 2 speeds"?
I'd figure there'd be no reason to mention a hub if you didn't use one.
Did you just get caught debating dirty? Yes, yes you did. Bad Gr8Apes! No soup for you!
Firewire is a bigger security threat than USB in many ways, namely that it is a bus with direct memory access, meaning it can read and write anything in RAM at any time. The USB attack vector has nothing to do with USB itself; it's a flaw in a poor quality devices that allow their firmwares to be reprogrammed, enabling them to act as a different class of device. There is no reason Firewire would not be vulnerable in the same way, were a Firewire device's firmware made writable in the same way as the vulnerable subset of USB devices; only the exposure would be worse, given Firewire's DMA. Likewise with Thunderbolt, as it also has DMA.
I love the fact that you can take over a computer by plugging in a storage device
Citation? Maybe there's something I missed, but I think you're thinking of this, in which case: Nope. Well, no more than a device with direct memory access. In fact, a little less.
Also, maybe try getting a USB3 hub that isn't a piece of shit. I don't have the speed problems you describe at all.
Your first paragraph refers to Canadian law, which may apply to you but does not apply to me, or to the majority of Slashdot readers. I can't argue with it as, from your position, you are perfectly correct. Your second paragraph is what's interesting to me, as that's exactly the point I was trying to make.
Actually, the first paragraph is interesting to me, as well, as I did not know that bit of Canadian law. Knowing that this is legally (and likely socially) enforced in Canada, I'd be willing to wager that it we compared the ratio of netcams with default passwords to netcams with non-default passwords in Canada and compared it with the same in the US, Canada would fare considerably better.
We need something like that here in the states, so people start taking a bit of fucking responsibility for themselves and their own actions. Though, if we had it, it would probably be applied to rape victims who wore short skirts and no panties, while being ignored in cases where someone leaves their door wide open and hangs a flashing neon "murder me" sign in the window. And people I know say Canada is backwards...
I'll refer you to my response to the first reply to that post. I have a feeling you know exactly what I was getting at, but, in case you don't, that should clarify.
It's also why Apple Pay counts as a card-present transaction, and Google Wallet doesn't.
From the retailer's perspective, actually, it does, as the virtual card Google Wallet presents is just as present as the details presented by Apple Pay. On Google's end, when they charge your card, it is not, so I guess you're partially correct. Assuming, of course, that you're funding your purchase with a credit card; it's a moot point if it's coming out of checking.
Actually, everybody had USB when the Mac had Firewire. Eventually, Apple caved in and added USB, then added USB support to the iPod, which was initially Firewire-only.
I'm sure you fully understand the point I'm trying to make and are just arguing semantics at this point, so I'll humor you for the sake of entertainment.
Technically, at that point, the key is no longer legally yours. That is, you may still posses it, but you no longer "have" it, in a legal sense, as you were to have turned it over to its rightful owner. Similarly, were the owner of a building, private residence or not, to put a lock on their door, and that lock included a bowl containning dozens of keys in a bowl labeled "Key to my house. Take one, they're free.", which they then proceeded to leave on their front porch, they would be legally giving that key and, with it, legal authority to enter through that door, to anyone who took one. That they can later revoke that authority on an individual basis does not change the fact that this is *exactly* what people are doing when they put a device on the public internet *with default credentials*.
If someone uses that key to come in and steal all their shit, that person is still a criminal; for stealing, though, not for entering, as they were given implicit permission by way of the key.
If the owner wishes to access that device remotely and don't wish for the device to be accessed by the general public, perhaps it would be wise to put a password on it? Not the default password that everybody and their mother knows, either; after all, it's not illegal to enter through a door for which you have a key.
The torrent client isn't implementing its own TCP stack, it's using the TCP stack provided by the OS. Other than that, I have no arguments with the rest of your post.
It's why the DMCA's "effectively controls access to a work" provision works with encryption
Because there's a clear intent, even if you use ROT13, that the DMCA was invoked.
Well, no, actually. In order for an encryption scheme to be considered "effective", it must not already be broken. ROT13 is most certainly broken. This is also the reason studios abandon known-broken DRM schemes; anything released before it was known broken is protected under the law, as the scheme was effective when implemented, but it wouldn't be considered "effectively control[ling] access", just the same as putting a known-bad lock on your door would be considered ineffective.
You need to revisit how TCP works. Absent traffic shaping, every TCP stream going over a link has the same opportunity as every other TCP stream going over the same link, so there is a definite advantage to having more streams than the other guy once you hit the backbone. BitTorrent, for example, exploits this be opening hundreds or thousands of connections at once.
Slashdot Mirror
Forgot to log in... yes, that post was mine.
I was relatively sure that part of the problem was that the system's USB controllers could also be coopted by plugging in a bad USB device, whether the system recognized said device or not.
Then you've not read up on the issue as much as your stong opinions on it would seem to imply.
Correct me if I'm oversimplifying the problem.
I've been trying...
I'll also bet your SSDs are on SATA connections, those are 1:1 internal, you mention that yourself.
You know what else I mentioned?
Then why don't I see an issue with it when I connect 2 portable drives (bare enclosures in which I've put a couple of Samsung SSDs) via a USB hub?
Indeed, I've been trying in vain, as you clearly don't read. Mind you, these are drive I use every day for high-speed media transfer. I'm sure I don't know WTF I'm talking about, though, and the world is just bending to my will. Right?
As you've shown a complete unwillingness to actually consider that you may be wrong, or to even read the posts you're replying to, let alone the linked information (because you're likely sure it'll prove you wrong), I think we're done here. I'm sure anyone reading this will have read everything, leaving you the only one who still thinks you're right.
You got my point, though...
I didn't see any of that in the Wired story. It essentially stated: "plug it in, it infects your PC, Antivirus software is useless, and future USB devices plugged into your system can be infected". When Bruce wrote about it along with quite a few others, the evidence seems to point to a rather bad security flaw.
Well, as USB itself does not provide DMA (again, this is requested and handled at the driver level), a USB device can do absolutely nothing until the system recognizes it and starts talking to it (e.g. via a driver). You clearly didn't follow what you've read, or you'd understand that the nature of this vulnerability is that many devices don't have firmware programming disabled and can be reprogrammed to behave as other devices (in fact, you do seem to understand this, as you said "The problem lies in that USB trusts the device to be what it says it is, even if that is more than one thing", which is correct; it's equally correct that a USB device can be more than one thing, e.g. an audio device and a video device, so that's not a flaw, the flaw is in the devices being reprogrammable in the first place). Which, of course, means the devices have to be identified by the system and a driver has to exist for whatever they identify as.
Further proof that it is a device issue here, and evidence that USB devices must be "accepted" by the host before they can to anything at all, here. Not that this should be necessary, given a basic understanding of what you're talking about and a bit of logic.
Meanwhile, devices utilizing any of the DMA-enabled buses*[1] can just power up and happily start reading and writing your RAM, with the system being unable to stop them. If a cheap Firewire device was shipped with its firmware still writable, well, just imagine the possibilities. In fact, it's been done and the sky hasn't fallen yet, so I think we're okay.
The short answer to this one is I only usually have 1 set of devices that are relatively permanent for those other buses. It's not a thumbdrive that gets passed around.
That's you; Firewire is still fairly widely used in media production, and the devices using it include cameras, control boards, and DAT decks, which do get passed around. And without USB, where do you think you'd plug that thumb drive?
Drop 2 sets of file transfers through the disks on that one hub, and see what happens.
Okay, so you're doing two copy operations and are surprised when seek times slow them by more than 50%? You don't copy files on spinning disks much, do you? I do it all the time, albeit with SSDs, and have not once seen the slowdown you are talking about, so either you're full of shit, your equipment is full of shit, or you don't really know where the slowdown is coming from, but none of that is the fault of USB.
I have about 10 disks hooked up and was copying files between 3 sets (3 full speed copy operations, including 2 SSDs) with each disk capable of +100MB/s on large file sequential read/write speeds.
Which is it, 10 or 2? One, two, or three transfers? All this goalpost moging makes me think you're just full of shit.
You state that your drives can handle 100MB/s; USB3 is 5gbps (that's 640MBps), while SATA is 1.5, 3., or 6gbps (187.5, 375, or 750MB/s) depending on whether you've got SATA I, II, or III ports. On a high-end mobo like you claim to own, it's probably SATA-III, so 6gbps. That includes a fair bit of overhead, so the best you can e
Now I almost feel bad for tearing you apart so bad in that other post. Almost.
Everybody had USB, I never said everybody used it. That said, I refer you to this post, with actual references, so you can see just how wrong you are. Firewire came out on 1994, by the way, on Macs, 4 years before they added USB to the iMac.
Or I just didn't pay attention to Apple in the '90s and was too lazy to look it up. As a 2000 grad, I'd say I lived through the 90's. I also tend to get my history right when it related to something I actually care about. That being said:
1) You're thinking of Windows 95, which didn't see USB support until OSR2.1.Windows 98 did, in fact, ship with USB support.
2) USB 1.0 debuted in 1995, USB 1.1 in 1998. The iMac G3 did drop legacy ports as you claim, but is that a pair of Firewire ports I see? Yes, because Firewire was Apple's darling at the time and not a legacy port
3) I won't argue this, as it's factually correct as far as I am aware; however: the first 2 iPod models did not support USB at all, and the 3 after it only supported sync, no charging via USB for them.
4) Yes, you do.
If they hang it in their front lawn... are you telling me it's illegal to look at it? Of course it's not legal to take,; but, then. nobody claimed it was fine to take someone's security camera because they didn't change the default password, either. Legal to view it? Well, yes, until such time that you could reasonably realize that they, perhaps, hadn't intended to make it public.
But, of course, you knew what I meant and were simply being obtuse for the sake of argument. Bravo.
There is a DMA component, a quick search reveals they haven't fixed that either yet.
You mean that drivers can determine whether they, themselves, require DMA? That's no worse than the device having DMA itself; in fact, it's damn sight better, given that Firewire device doesn't even have to identify itself, let alone have that identity accepted by the system, to gain that level of access, meanwhile a USB device must identify itself as a device whose driver required DMA, that driver must be present, and it must emulate that device well enough to fool the driver into actually talking to it; the bar is a fair bit higher with USB than DMA.
The problem lies in that USB trusts the device to be what it says it is, even if that is more than one thing.
That's all fine and dandy, the device still has to fool the driver, as well, whereas the OHCI 1394 specification (aka Firewire) allows for devices for performance reasons to bypass the operating system and access physical memory directly without any security restrictions.. In case Wikipedia isn't a strong enough source for you, here is the actual specification. A Firewire or Thunderbolt device or, as you correctly point out, ecpressCard, PCI, PCI-express (though you're really repeating yourself with that list) device doesn't even need OS or driver cooperation to be rejected by your system, it just pops on the bus and says "Let me see this RAM" and gets what it wants. Hell, it can do that repeatedly until it finds the bit of vulnerable code it's after and immediately turn around and overwrite it with an exploit. Actually, there's nothing stopping it from using that method to exploit your OS' I/O stack to allow itself to write arbitrary files on disk. All with no drivers, or authentication.
If you're worried about USB, you need to be terrified about the other busses in your system.
I was referring to WIred's story[...] ... which provides the same details about the same thing (BadUSB). So, then, I was right? You were talking about BadUSB? Good.
The slow down is a direct result of the design of USB serial communications.
Then why don't I see an issue with it when I connect 2 portable drives (bare enclosures in which I've put a couple of Samsung SSDs) via a USB hub? Also, if not a hub, why did you say:
"Hook 2 devices up to a USB 3 hub, watch yourself get lower than USB 2 speeds"?
I'd figure there'd be no reason to mention a hub if you didn't use one.
Did you just get caught debating dirty? Yes, yes you did. Bad Gr8Apes! No soup for you!
I love the fact that you can take over a computer by plugging in a storage device
Citation? Maybe there's something I missed, but I think you're thinking of this, in which case: Nope. Well, no more than a device with direct memory access. In fact, a little less.
Also, maybe try getting a USB3 hub that isn't a piece of shit. I don't have the speed problems you describe at all.
Your first paragraph refers to Canadian law, which may apply to you but does not apply to me, or to the majority of Slashdot readers. I can't argue with it as, from your position, you are perfectly correct. Your second paragraph is what's interesting to me, as that's exactly the point I was trying to make.
Actually, the first paragraph is interesting to me, as well, as I did not know that bit of Canadian law. Knowing that this is legally (and likely socially) enforced in Canada, I'd be willing to wager that it we compared the ratio of netcams with default passwords to netcams with non-default passwords in Canada and compared it with the same in the US, Canada would fare considerably better.
We need something like that here in the states, so people start taking a bit of fucking responsibility for themselves and their own actions. Though, if we had it, it would probably be applied to rape victims who wore short skirts and no panties, while being ignored in cases where someone leaves their door wide open and hangs a flashing neon "murder me" sign in the window. And people I know say Canada is backwards...
I'll refer you to my response to the first reply to that post. I have a feeling you know exactly what I was getting at, but, in case you don't, that should clarify.
Supporting documentation?
It's also why Apple Pay counts as a card-present transaction, and Google Wallet doesn't.
From the retailer's perspective, actually, it does, as the virtual card Google Wallet presents is just as present as the details presented by Apple Pay. On Google's end, when they charge your card, it is not, so I guess you're partially correct. Assuming, of course, that you're funding your purchase with a credit card; it's a moot point if it's coming out of checking.
Actually, everybody had USB when the Mac had Firewire. Eventually, Apple caved in and added USB, then added USB support to the iPod, which was initially Firewire-only.
I'm sure you fully understand the point I'm trying to make and are just arguing semantics at this point, so I'll humor you for the sake of entertainment.
Technically, at that point, the key is no longer legally yours. That is, you may still posses it, but you no longer "have" it, in a legal sense, as you were to have turned it over to its rightful owner. Similarly, were the owner of a building, private residence or not, to put a lock on their door, and that lock included a bowl containning dozens of keys in a bowl labeled "Key to my house. Take one, they're free.", which they then proceeded to leave on their front porch, they would be legally giving that key and, with it, legal authority to enter through that door, to anyone who took one. That they can later revoke that authority on an individual basis does not change the fact that this is *exactly* what people are doing when they put a device on the public internet *with default credentials*.
If someone uses that key to come in and steal all their shit, that person is still a criminal; for stealing, though, not for entering, as they were given implicit permission by way of the key.
Wait... it's illegal to enter through a door for which you have a key? Since the fuck when?
WoW is not the last game that was not released on a console
I know, that's why my comment opened with
It's not actually the last PC only game they released
It was, however, only released on Personal Computer platforms, including Windows, OSX, and a Linux beta.
It is also what the person I was replying to was looking for as an answer, to make a point about PC only games being able to attract large userbases.
It's not actually the last PC only game they released, but I think the answer you're looking for is World of Warcraft.
If the owner wishes to access that device remotely and don't wish for the device to be accessed by the general public, perhaps it would be wise to put a password on it? Not the default password that everybody and their mother knows, either; after all, it's not illegal to enter through a door for which you have a key.
The torrent client isn't implementing its own TCP stack, it's using the TCP stack provided by the OS. Other than that, I have no arguments with the rest of your post.
It's why the DMCA's "effectively controls access to a work" provision works with encryption
Because there's a clear intent, even if you use ROT13, that the DMCA was invoked.
Well, no, actually. In order for an encryption scheme to be considered "effective", it must not already be broken. ROT13 is most certainly broken. This is also the reason studios abandon known-broken DRM schemes; anything released before it was known broken is protected under the law, as the scheme was effective when implemented, but it wouldn't be considered "effectively control[ling] access", just the same as putting a known-bad lock on your door would be considered ineffective.
If something is displayed publicly, it's *very* reasonable to assume it's intended to be public.
Let me know when they get the price down to $5 and I'll buy two.
You need to revisit how TCP works. Absent traffic shaping, every TCP stream going over a link has the same opportunity as every other TCP stream going over the same link, so there is a definite advantage to having more streams than the other guy once you hit the backbone. BitTorrent, for example, exploits this be opening hundreds or thousands of connections at once.