Instead of a read-only firmware, OpenWrt has a fully writable filesystem with package management.
For devices like this, firmware should have a hardware-enforced read-only setting that is on by default. Signed binaries are only as "secure" as the master signing keys, and if I can't install my own firmware I don't really "own" it, now do I?
If I want to flash my firmware, I should have to toggle a switch.
Granted, if the router is going to be in an out-of-the-way place, then I might need to leave that switch enabled all the time, leaving me vulnerable to fake updates. But for everyone else, hardware should prevent a bad actor from installing a new binary, signed (with a stolen key) or not.
If you put stolen blood on a comic book, does the whole comic book - or at least the part of the book the blood soaked into - become "stolen goods" in the eyes of the law?
That guy must've been wearing a "joker hat" - he wound up with nothing except the "joy" of seeing a bunch of people having to deal with cleaning up his mess, just like Gotham City's Joker.
A white hat would've reported the bug quietly. A black hat would've capitalized on it with a lot more "smarts" so he wouldn't walk away with nothing.
A grey hat would've done something in between, but he wouldn't have done it just for the lulz.
The other day my cc got used to make a $5 donation to some Christian website that I had never heard of.
That was a smart crook.
1) It validated the card was good or not.
2) If their victim was married, he might wait to call the bank until he talked to his spouse, because "giving to charity" is something many people would do without checking with their spouse first. This buys the crook time to do real damage.
3) Giving small amounts to charity is something a lot of people do, so it's less likely to be flagged by the bank as suspicious than, say, spending money at a far-away-from-the-victim brick-and-mortar store.
In your case, it was flagged. Perhaps there was something about THAT charity that raised a red flag with the bank. Perhaps there was a rash of "$5 charity donations" in the last few days so your bank or all banks were on the lookout for that type of transaction. Perhaps your bank figured out that you never give to charity using that credit card, so when you did, it raised a red flag. In any case, I think the "$5 charity donation" was a good gamble by the crooks. They lost, but it was still a good gamble.
Someone at MS modified code without understanding all the implications, and/or they modified code and someone else at MS called the code without being aware of the modification.
"Forking open source code" could just as easily been "bought closed-source project from third party them modified it," "hired contractor to write a library then modified it," or "forked code from another MS project then modified it."
When you first activate it, the first time you use it you will get an alert and have a few days to do a second activation.
Until the 2nd activation goes through, you will get an alert on all charges and if it's a high-dollar charge or even a medium-dollar charge at someplace that's not "normal" for you, the charge will be declined and alarms would go off at the bank and on my phone or email.
So, if someone pulls the switcheroo on my card they might be able to buy a $100 TV at a local merchant but I would know about it nearly instantly and call the bank and police. They wouldn't be able to buy that $5000 gold ring, the charge would be declined.
If he'd kept the mining down to a high-but-not-suspicious level he could've mined for weeks and sold his Verge for USD nd walked away with tens or hundreds of thousands of dollars by summer and maybe millions by Christmas.
Hmm, maybe he or one of is buddies did and this is his way of "shutting the whole exploit down."
Again, if memory serves, there were at least two pre-releases of MacBasic interpreters in circulation. The first was pretty much like the BASIC language used with other early-1980s computers, with line numbers.
The second version was more Pascal-like in that it did not require line numbers and it used GOSUB or some variant of it. I do not remember if GOSUB had parameter-passing and, if it did, I do not remember the semantics of how parameters were passed.
If memory serves it was one of the early C compiler vendors. It wasn't Lightspeed C, Think C, or any of their successors (companies got bought out in that era and product names changed). Of course it wasn't Apple's either.
I say "if memory serves" because after over 3 decades, my memory is probably as reliable as floppy disks these compilers were shipped on, if that.
Apple said "if you follow the rules laid out in Inside Macintosh then future operating system updates will not break your code."
If your code was compiled against your compiler-vendor's libraries and those libraries didn't follow Apple's rules, then it's no surprise your code - and everyone else's who used the same compiler - suddenly broke when Apple updated their operating system.
The only surprise was that a compiler vendor - whose job included not offending its own customers - would be that stupid.
Your point about not being connected to the internet is well taken. Back then, most Mac users received updates either through downloads from dialup bulletin board systems, visits to their local computer store via floppy disks, or if they were at a university or other institution with internet access, via ftp from Apple's ftp server.
Back in '85 or '86, all apps compiled with a popular compiler suddenly stopped working because the compiler vendor didn't follow all of the rules in Inside Macintosh.
As a result, all the applications built with their tools also stopped working.
Back in those days, when an app crashed, it usually took your computer with it.
On the bright side, your built-in monitor - the only monitor you had - still worked after a reboot.
Stallman sounds like he would be happy in a "bare bones, no personalized customer service" world.
The opposite extreme is full-bore "we know you better than your mother/spouse does" concierge service, which requires knowing your needs, likes, and dislikes pretty intimately.
The real world, where the restaurant waiter that you like best knows when you come in, what table you like, and what food you like but on his day off the backup waiter probably does not unless you've enrolled in the restaurant's customer-rewards program (or it's a classy place where waiters "train" their backups), is in between.
What is the "basic function" of a restaurant is in the eye of the customer, and that will determine what amount of information needs to be collected. Do you, the restaurant patron, want just food, do you want just a decent one-time experience, or do you want an ongoing experience with a particular waiter or maybe the entire staff of a favorite restaurant? If you want more than a decent one-time experience, you will EXPECT the restaurant or its waiters to learn your names and what you like. If you just want a one-off experience or "just food" and you think like Stallman does, you will want the waiter to conveniently forget you ever existed the moment you walk out and the bill payment clears.
While your point is valid in theory, is does not completely explain the gender disparity in STEM and, for that matter, in other fields.
In a "perfect" world where there was no gender-specific pressure to pursue careers, I would expect most fields (all except those few which depend on gender-specific physical or psychological attributes) to be a lot closer to 50/50 than they are in most STEM fields are today in the United States.
In America, there are still too many teenagers and young adults whose early educational years had gender biases that "pushed" people toward certain fields and away from others based on their gender. I do not know if this is still true for today's under-10-year-olds but even if it's not, it will be at least 15 years for the existing bias to stop appearing in the statistics of career choices of fresh college graduates.
In America, there is also still some degree of "male favoritism" in many of the STEM fields once you start a career. Sadly, there are still a few managers who will treat male employees better than female employees simply because they are male or, more subtly, simply because they travel in the same male-dominated social circles.
Each year the Fee Software award goes to someone making "a great contribution to the progress and development of free software, through activities that accord with the spirit of free software." [emphasis added]
I don't remember all of the social media accounts, phone numbers, and email addresses I've used in the last 5 years.
Many of them are one-shot-throw-aways that I use to fill in online complaint forms. Their sole purpose is to receive the reply to the complaint - usually nothing more than the automated "your complaint has been registered" reply.
If this becomes a standard worldwide, I'll be forced to stay at home.
Open source often manages to give you all three [fast, cheap, and good].
Measure the cost in man-hours instead of "how much the end user paid for it" and "cheap" tends to disappear.
I will grant you one major difference between a large-team distributed project - most large FOSS projects are distributed - and a large-team project run by a single entity: Project management is usually very different, and as a result, the cost of project management may be very different.
A completely separate Computer-On-A-Chip that has NO physical connection to the rest of the system but is inside the same laptop casing for convenience lets you attack that system how?
It probably shares access to the screen, keyboard, trackpad/mouse, one or more network devices, and maybe one or more USB or other ports. It may even share access to the onboard hard drive or SSD.
It likely also shares access to the integrated controllers and firmware for said devices.
Each of these has to be carefully scrutinized to make sure buffers are scrubbed both during power-off and during reboot. They also need to be carefully examined for the possibility of side-channel attacks.
There is also user training to tell users they should do a full shutdown and remove any external devices before rebooting to the "other" OS, or that can also be an attack vector. They also need to be trained that even if such devices are removed, if they are used in both environments they should be "proven safe" first, not just "presumed safe."
That's a lot of work.
On the other hand, the user training isn't much more than in a two-pc or two-VM system.
I will concede that I do not know of any specific, known attack vectors in such a situation, but, as you can see from what I wrote above, there are some "known unknowns" and possibly some "unknown unknowns" when it comes to the risks of a two-in-one system.
As others have said, run both the "secure" and "internet" OSes as virtual machines under a plain-jane hypervisor or host-OS that you use only to run the VMs under, and nothing else.
Unless someone exploits a bug or you do something stupid or careless - like carelessly access the internet from your host OS - you should be fine.
Locking down the host OS or hypervisor and keeping it patched is left as an exercise to the reader.
== That said, there are no doubt cases where having a "two in one" computer is better than having two seperate computers or having two VMs running on the same hardware, but the number of such cases is small enough that it's no wonder there's not much of a market out there for such devices.
The scenario you mention is best solved by either a VM solution or, if there is a strict legal requirement that even a VM can't solve, using two computers. Why two computers? Because the cost of geting a 2-in-one computer that is certified to meet your legal requirement is probably way more than the "cost" - including the "pain in the butt cost" - of buying and using two computers.
Slashdot Mirror
Security is almost always bolted on later, after the asshats start moving in.
It will be fixed... at great public expense.... when the asshats start exploiting it.
Maybe they will.
Maybe enough asshats will be caught to deter those doing it for the lulz.
Maybe they will become obsolete and just be turned off, like analog cell services.
Instead of a read-only firmware, OpenWrt has a fully writable filesystem with package management.
For devices like this, firmware should have a hardware-enforced read-only setting that is on by default. Signed binaries are only as "secure" as the master signing keys, and if I can't install my own firmware I don't really "own" it, now do I?
If I want to flash my firmware, I should have to toggle a switch.
Granted, if the router is going to be in an out-of-the-way place, then I might need to leave that switch enabled all the time, leaving me vulnerable to fake updates. But for everyone else, hardware should prevent a bad actor from installing a new binary, signed (with a stolen key) or not.
If you put stolen blood on a comic book, does the whole comic book - or at least the part of the book the blood soaked into - become "stolen goods" in the eyes of the law?
That guy must've been wearing a "joker hat" - he wound up with nothing except the "joy" of seeing a bunch of people having to deal with cleaning up his mess, just like Gotham City's Joker.
A white hat would've reported the bug quietly. A black hat would've capitalized on it with a lot more "smarts" so he wouldn't walk away with nothing.
A grey hat would've done something in between, but he wouldn't have done it just for the lulz.
The other day my cc got used to make a $5 donation to some Christian website that I had never heard of.
That was a smart crook.
1) It validated the card was good or not.
2) If their victim was married, he might wait to call the bank until he talked to his spouse, because "giving to charity" is something many people would do without checking with their spouse first. This buys the crook time to do real damage.
3) Giving small amounts to charity is something a lot of people do, so it's less likely to be flagged by the bank as suspicious than, say, spending money at a far-away-from-the-victim brick-and-mortar store.
In your case, it was flagged. Perhaps there was something about THAT charity that raised a red flag with the bank. Perhaps there was a rash of "$5 charity donations" in the last few days so your bank or all banks were on the lookout for that type of transaction. Perhaps your bank figured out that you never give to charity using that credit card, so when you did, it raised a red flag. In any case, I think the "$5 charity donation" was a good gamble by the crooks. They lost, but it was still a good gamble.
I hope the crooks got caught and prosecuted.
Maybe they used a version with a license similar to this one.
Nothing to see here.
Someone at MS modified code without understanding all the implications, and/or they modified code and someone else at MS called the code without being aware of the modification.
"Forking open source code" could just as easily been "bought closed-source project from third party them modified it," "hired contractor to write a library then modified it," or "forked code from another MS project then modified it."
If the statute of limitations hasn't run out, sue the bank for the money and subpoena Fry's for their camera footage.
OK, how about a 2-stage activation:
When you first activate it, the first time you use it you will get an alert and have a few days to do a second activation.
Until the 2nd activation goes through, you will get an alert on all charges and if it's a high-dollar charge or even a medium-dollar charge at someplace that's not "normal" for you, the charge will be declined and alarms would go off at the bank and on my phone or email.
So, if someone pulls the switcheroo on my card they might be able to buy a $100 TV at a local merchant but I would know about it nearly instantly and call the bank and police. They wouldn't be able to buy that $5000 gold ring, the charge would be declined.
If he'd kept the mining down to a high-but-not-suspicious level he could've mined for weeks and sold his Verge for USD nd walked away with tens or hundreds of thousands of dollars by summer and maybe millions by Christmas.
Hmm, maybe he or one of is buddies did and this is his way of "shutting the whole exploit down."
We will probably never know.
Again, if memory serves, there were at least two pre-releases of MacBasic interpreters in circulation. The first was pretty much like the BASIC language used with other early-1980s computers, with line numbers.
The second version was more Pascal-like in that it did not require line numbers and it used GOSUB or some variant of it. I do not remember if GOSUB had parameter-passing and, if it did, I do not remember the semantics of how parameters were passed.
If memory serves it was one of the early C compiler vendors. It wasn't Lightspeed C, Think C, or any of their successors (companies got bought out in that era and product names changed). Of course it wasn't Apple's either.
I say "if memory serves" because after over 3 decades, my memory is probably as reliable as floppy disks these compilers were shipped on, if that.
freeze123:
Basically, what AC said in #56381037 above.
But to elaborate:
Apple said "if you follow the rules laid out in Inside Macintosh then future operating system updates will not break your code."
If your code was compiled against your compiler-vendor's libraries and those libraries didn't follow Apple's rules, then it's no surprise your code - and everyone else's who used the same compiler - suddenly broke when Apple updated their operating system.
The only surprise was that a compiler vendor - whose job included not offending its own customers - would be that stupid.
Your point about not being connected to the internet is well taken. Back then, most Mac users received updates either through downloads from dialup bulletin board systems, visits to their local computer store via floppy disks, or if they were at a university or other institution with internet access, via ftp from Apple's ftp server.
Back in '85 or '86, all apps compiled with a popular compiler suddenly stopped working because the compiler vendor didn't follow all of the rules in Inside Macintosh.
As a result, all the applications built with their tools also stopped working.
Back in those days, when an app crashed, it usually took your computer with it.
On the bright side, your built-in monitor - the only monitor you had - still worked after a reboot.
Stallman sounds like he would be happy in a "bare bones, no personalized customer service" world.
The opposite extreme is full-bore "we know you better than your mother/spouse does" concierge service, which requires knowing your needs, likes, and dislikes pretty intimately.
The real world, where the restaurant waiter that you like best knows when you come in, what table you like, and what food you like but on his day off the backup waiter probably does not unless you've enrolled in the restaurant's customer-rewards program (or it's a classy place where waiters "train" their backups), is in between.
What is the "basic function" of a restaurant is in the eye of the customer, and that will determine what amount of information needs to be collected. Do you, the restaurant patron, want just food, do you want just a decent one-time experience, or do you want an ongoing experience with a particular waiter or maybe the entire staff of a favorite restaurant? If you want more than a decent one-time experience, you will EXPECT the restaurant or its waiters to learn your names and what you like. If you just want a one-off experience or "just food" and you think like Stallman does, you will want the waiter to conveniently forget you ever existed the moment you walk out and the bill payment clears.
While your point is valid in theory, is does not completely explain the gender disparity in STEM and, for that matter, in other fields.
In a "perfect" world where there was no gender-specific pressure to pursue careers, I would expect most fields (all except those few which depend on gender-specific physical or psychological attributes) to be a lot closer to 50/50 than they are in most STEM fields are today in the United States.
In America, there are still too many teenagers and young adults whose early educational years had gender biases that "pushed" people toward certain fields and away from others based on their gender. I do not know if this is still true for today's under-10-year-olds but even if it's not, it will be at least 15 years for the existing bias to stop appearing in the statistics of career choices of fresh college graduates.
In America, there is also still some degree of "male favoritism" in many of the STEM fields once you start a career. Sadly, there are still a few managers who will treat male employees better than female employees simply because they are male or, more subtly, simply because they travel in the same male-dominated social circles.
It took more than a few minutes but the typo is fixed.
Since you mentioned Linux and women, I have to ask, do you mean the "wall" that keeps women from rising to near-parity with men in STEM fields?
That wall has been up longer than I've been alive and it's long past time it came down.
Each year the Fee Software award goes to someone making "a great contribution to the progress and development of free software, through activities that accord with the spirit of free software." [emphasis added]
Sometimes spell-check just isn't enough.
I don't remember all of the social media accounts, phone numbers, and email addresses I've used in the last 5 years.
Many of them are one-shot-throw-aways that I use to fill in online complaint forms. Their sole purpose is to receive the reply to the complaint - usually nothing more than the automated "your complaint has been registered" reply.
If this becomes a standard worldwide, I'll be forced to stay at home.
Until 2002, the .us domain operated as a locality namespace with very few 2nd-level-sub-domains other than the 50 individual states in the USA.
For governments and other organizations that were inherently geographical, using the .us country domain made a lot of sense.
Open source often manages to give you all three [fast, cheap, and good].
Measure the cost in man-hours instead of "how much the end user paid for it" and "cheap" tends to disappear.
I will grant you one major difference between a large-team distributed project - most large FOSS projects are distributed - and a large-team project run by a single entity: Project management is usually very different, and as a result, the cost of project management may be very different.
"Fast, good, cheap, pick (no more than) two."
Sometimes you only get to pick one, or none.
A completely separate Computer-On-A-Chip that has NO physical connection to the rest of the system but is inside the same laptop casing for convenience lets you attack that system how?
It probably shares access to the screen, keyboard, trackpad/mouse, one or more network devices, and maybe one or more USB or other ports. It may even share access to the onboard hard drive or SSD.
It likely also shares access to the integrated controllers and firmware for said devices.
Each of these has to be carefully scrutinized to make sure buffers are scrubbed both during power-off and during reboot. They also need to be carefully examined for the possibility of side-channel attacks.
There is also user training to tell users they should do a full shutdown and remove any external devices before rebooting to the "other" OS, or that can also be an attack vector. They also need to be trained that even if such devices are removed, if they are used in both environments they should be "proven safe" first, not just "presumed safe."
That's a lot of work.
On the other hand, the user training isn't much more than in a two-pc or two-VM system.
I will concede that I do not know of any specific, known attack vectors in such a situation, but, as you can see from what I wrote above, there are some "known unknowns" and possibly some "unknown unknowns" when it comes to the risks of a two-in-one system.
As others have said, run both the "secure" and "internet" OSes as virtual machines under a plain-jane hypervisor or host-OS that you use only to run the VMs under, and nothing else.
Unless someone exploits a bug or you do something stupid or careless - like carelessly access the internet from your host OS - you should be fine.
Locking down the host OS or hypervisor and keeping it patched is left as an exercise to the reader.
==
That said, there are no doubt cases where having a "two in one" computer is better than having two seperate computers or having two VMs running on the same hardware, but the number of such cases is small enough that it's no wonder there's not much of a market out there for such devices.
The scenario you mention is best solved by either a VM solution or, if there is a strict legal requirement that even a VM can't solve, using two computers. Why two computers? Because the cost of geting a 2-in-one computer that is certified to meet your legal requirement is probably way more than the "cost" - including the "pain in the butt cost" - of buying and using two computers.