In my opinion, the decision rules the Pauls give regarding Internet regulation are basically good, but:
They should come out and state whether they think a private toll road company can prohibit transit by a competing contractor (which is the analogue of Verizon prohibiting or manipulating Google, Netflix, etc.).
If not, then why should Internet pipe providers have that ability, too?
Why we need WikiLeaks: Remember the article on the Australian tax authority the other day where they want expansive powers to snoop on businesses on the off-chance they might be paying less taxes than the government would like?
OK, then, we the citizens need powers to snoop on government bureaucrats on the off-chance they're doing something illegal. If they're not doing anything wrong, they should have nothing to fear.
Each governmental agency thinks it's an entity unto itself. Everything depends on this one agency. Every right and freedom must be subjugated to meeting the agency's goal.
Whether it's taxation, "homeland" security, child protection, consumer protection, cops, military, unions or any number of other things, everybody wants their agency to figure first in citizen's lives.
It's time for people to stand up for the principle that government may only exercise those powers expressly granted to it. All other powers are reserved to the people.
Obviously, no CMS or CMF is asking you for code and then executing it.
Normally, people use it like this:
Example 1: Access permission on a certain page. The CMS lets you a) show the page to all users, b) show only to users with a given role, or c) show only if you return "true" from a PHP function, which you enter into the CMS and it's saved in the DB.
Example 2: In a given content block, you can enter (on the backend) plain text, filtered HTML, full HTML, or PHP.
As I said above, it's better not to use this functionality. But there you go.
The potential for harm exists in that you could have a PHP injection problem if you reuse something from the environment (GET or POST or whatever).
Just to be sure you understand what I'm saying, forget the CMS, and let's just take the simplest case:
You've got a single PHP file, say test.php .
test.php has a text box in which you can enter some PHP code, and a Submit button.
Once you submit, in test.php, you've got the PHP code in, say $phpcode.
Now, to execute it, just do: eval( $phpcode);
That's it.
Of course, you wouldn't want a file like that anywhere on your website, but that's how dynamic PHP works. Also, it's not meant for the purpose of executing code you type into a text box. It's just some level of flexibility included in PHP (and most other scripting languages).
1. First, yes, we agree that if you're root, you can do anything.
2. But, again, yes I was talking about admin on the website software, whatever it is. And that would be "guy with all permissions". Of course normally, you should set up and use lower privilege accounts, which contain the bare minimum of stuff you need to do your daily tasks. Only log in as admin once in a while.
3. However, let's say you are logged in as site admin. And you go to badsite.example.com, and they manage through some combination of bugs in your browser, CMS, and non-secure possibly wifi connection to execute commands as site admin.
4. Assuming #3, yes, an attacker should be able to execute arbitrary PHP.
a. First of all, he can probably upload a PHP file and navigate to that.
b. Or, run dynamic PHP with eval(). Example in Drupal. Like it says "While this is a powerful and flexible feature if used by a trusted user with PHP experience, it is a significant and dangerous security risk in the hands of a malicious user." But, it's enabled on many sites anyway for the flexibility it offers. ("You go to war with the PHP site you have, not the one you want.")
My recommendation: log in with the least privilege necessary. And turn dynamic PHP in your CMS.
Note: You can turn off the eval() function in php.ini with disable_functions. However, many PHP CMSs and frameworks make use of it for some of their dynamic magic/polymorphism/etc.
It seems you're not really familiar with how this works in PHP, so I'll explain it:
If you're on the server as shell user, you can both 1) create a PHP file in your home directory (or wherever you have perms) and execute it via the command line. 2) Execute dynamic PHP (i.e., code that you make up on the spot) via the exec("php code goes here") function. That goes without saying.
Additionally, the mod_php Apache module allows the webserver to execute PHP files. Also, many PHP-based CMS's allow you to enter PHP to be executed at specified time or events. This PHP is saved in the database, retrieved, and then executed (via exec).
But that doesn't mean anybody who signs up as a user on the website can execute PHP.
If, somehow, you could impersonate the admin, then anything is fair game.
However, of course, anything would be fair game in a Java-based setup, too, since DB passwords are stored in plain text there, too. Also, you can run dynamic Groovy (Java scripting language).
In addition, CMSs such as Drupal which allow you to execute dynamic PHP also warn you not to do so. You can turn off the facility, as well. I would say that all your PHP should be in files. And you should turn off perms for "other". The files should be owned by you, and the webserver should run as you (meaning your user), not as "www-data" or whatever. That prevents nice and easy updates, but it's better.
Well, here's a route to that: If you can somehow manage to send messages to the controller as the admin, then:
1. let's say you're running a PHP CMS, as many/most websites are. 2. many PHP CMS's allow you to execute arbitrary PHP (if you have appropriate perms). 3. the DB username/password is normally contained in a PHP file 4. if you can execute arbitrary PHP, you can probably already execute arbitrary SQL using the CMS APIs. Or you can read the DB username/password and use that, or send it off somewhere.
OK, they might have taught you that in college. But they didn't necessarily teach everybody that.
In any case, every there's a post about college on/., most posters come out to say that college isn't about learning the specifics of development (like frameworks, SCM, etc.). It's about learning the theory of computer science. Learning minutiae is for trade school.
If that's the case, then people who studied the science of computing would have no clue about SQL injection. There's really no place you'd be able to learn, except if 1) you happen to get a good mentor at your first job, or 2) you happen to read about it on the Interwebs.
This. What exactly is it that you want to see with this much resolution?
The thin wires that hold props and whatnot in place for movies? Look, it's supposed to be a suspension of belief. That's what's required for a work of fiction. Too high of a resolution ruins the effect. Not to mention who wants to see every pore of every actor's face?
Even for documentaries: What's the point? Do you require this much resolution IRL? I'd venture to guess if you had an ultra-high resolution view of your pillow (including dust mites) you'd probably not be able to sleep.
Latest? Actually, if you want to be the "latest" you should send your email at exactly 8:01 AM.
One of the things that sort of nutty about email is the earlier emails get read last, just because of the sorting.
If you send a series of emails in which you patiently explain a bunch of things, and then in the following emails, you go into detail on some of those subjects, your readers will get the detail emails first (in their sorting).
People aren't necessarily carrying around customer cc numbers on their phones.
Rather, when you blur the lines of work and home, you make it easier for attackers to get in an in to the corporate network, where they they proceed to grab what they want to.
If you have a work-issued machine, the lines are clear: Work stuff is on the work phone/laptop/whatever, and it's password protected. Home stuff is on your device.
If it's BYOD, and Junior wants to play games on you iPhone, you just handed him a device that has your work stuff on it. If it's your own device, it's much more likely to be less protected and touched by more hands than a work device.
All those stories on the/. frontpage about credit card numbers stolen? They start with little leaks, and then the attacker wiggles his way in.
One thing, though: It's generally considered that Apple pays workers more than the going rate. And they have pretty good benefits in Apple Stores, too. Finally, they give them a good deal of ego boost ("respect").
Still, that didn't prevent all these shenanigans.
Basically: "Trust, but verify", and I'm asking about the verify part.
The reason, of course, is people are always ready to "soak the rich" when it's someone else getting wet. When the "rich" include them, then they suddenly think everyone should pay equally.
Slashdot Mirror
In my opinion, the decision rules the Pauls give regarding Internet regulation are basically good, but:
They should come out and state whether they think a private toll road company can prohibit transit by a competing contractor (which is the analogue of Verizon prohibiting or manipulating Google, Netflix, etc.).
If not, then why should Internet pipe providers have that ability, too?
>yes, they do give some reasons too, but not enough to really establish their case
Wait, are you talking about the GOP platform, or the Pauls' whitepaper on the Internet?
Because for the former, they're not really supposed to give reasons. It's a platform, which is basically just a list of stuff you believe in.
Reasons are generally included, or if they are, just the bare minimum.
applications?
or Apps(R)?
1. They use touchpads in 2001.
2. They use PADDs in Star Trek.
3. Apple copies from #1 and #2.
4. Android is used to build real versions of #1 and #2.
5. Apple sues #4.
6. Profit!
That's brilliant. Somebody in Samsung, do this.
If you're spending a billion, what's a million more?
"I'm Steve Jobs' daughter, the one he tried to deny. I love using my Galaxy S3."
We need a new movement.
The first phase of government transparency was the Freedom of Information Act, followed by similar acts at the state level.
The next phase needs to be cameras installed in every government official's office, running all the time, and accessible via web (defense excepted).
Backroom deals, sweetheart contracts, all that stuff: either capture on camera or prevent it from happening or make it much more difficult.
Why we need WikiLeaks: Remember the article on the Australian tax authority the other day where they want expansive powers to snoop on businesses on the off-chance they might be paying less taxes than the government would like?
OK, then, we the citizens need powers to snoop on government bureaucrats on the off-chance they're doing something illegal. If they're not doing anything wrong, they should have nothing to fear.
the power to destroy
Each governmental agency thinks it's an entity unto itself. Everything depends on this one agency. Every right and freedom must be subjugated to meeting the agency's goal.
Whether it's taxation, "homeland" security, child protection, consumer protection, cops, military, unions or any number of other things, everybody wants their agency to figure first in citizen's lives.
It's time for people to stand up for the principle that government may only exercise those powers expressly granted to it. All other powers are reserved to the people.
Obviously, no CMS or CMF is asking you for code and then executing it.
Normally, people use it like this:
Example 1: Access permission on a certain page. The CMS lets you a) show the page to all users, b) show only to users with a given role, or c) show only if you return "true" from a PHP function, which you enter into the CMS and it's saved in the DB.
Example 2: In a given content block, you can enter (on the backend) plain text, filtered HTML, full HTML, or PHP.
As I said above, it's better not to use this functionality. But there you go.
The potential for harm exists in that you could have a PHP injection problem if you reuse something from the environment (GET or POST or whatever).
Just to be sure you understand what I'm saying, forget the CMS, and let's just take the simplest case:
You've got a single PHP file, say test.php .
test.php has a text box in which you can enter some PHP code, and a Submit button.
Once you submit, in test.php, you've got the PHP code in, say $phpcode.
Now, to execute it, just do:
eval( $phpcode);
That's it.
Of course, you wouldn't want a file like that anywhere on your website, but that's how dynamic PHP works. Also, it's not meant for the purpose of executing code you type into a text box. It's just some level of flexibility included in PHP (and most other scripting languages).
1. First, yes, we agree that if you're root, you can do anything.
2. But, again, yes I was talking about admin on the website software, whatever it is. And that would be "guy with all permissions". Of course normally, you should set up and use lower privilege accounts, which contain the bare minimum of stuff you need to do your daily tasks. Only log in as admin once in a while.
3. However, let's say you are logged in as site admin. And you go to badsite.example.com, and they manage through some combination of bugs in your browser, CMS, and non-secure possibly wifi connection to execute commands as site admin.
4. Assuming #3, yes, an attacker should be able to execute arbitrary PHP.
a. First of all, he can probably upload a PHP file and navigate to that.
b. Or, run dynamic PHP with eval(). Example in Drupal. Like it says "While this is a powerful and flexible feature if used by a trusted user with PHP experience, it is a significant and dangerous security risk in the hands of a malicious user." But, it's enabled on many sites anyway for the flexibility it offers. ("You go to war with the PHP site you have, not the one you want.")
My recommendation: log in with the least privilege necessary. And turn dynamic PHP in your CMS.
Note: You can turn off the eval() function in php.ini with disable_functions. However, many PHP CMSs and frameworks make use of it for some of their dynamic magic/polymorphism/etc.
It seems you're not really familiar with how this works in PHP, so I'll explain it:
If you're on the server as shell user, you can both 1) create a PHP file in your home directory (or wherever you have perms) and execute it via the command line. 2) Execute dynamic PHP (i.e., code that you make up on the spot) via the exec("php code goes here") function. That goes without saying.
Additionally, the mod_php Apache module allows the webserver to execute PHP files. Also, many PHP-based CMS's allow you to enter PHP to be executed at specified time or events. This PHP is saved in the database, retrieved, and then executed (via exec).
But that doesn't mean anybody who signs up as a user on the website can execute PHP.
If, somehow, you could impersonate the admin, then anything is fair game.
However, of course, anything would be fair game in a Java-based setup, too, since DB passwords are stored in plain text there, too. Also, you can run dynamic Groovy (Java scripting language).
In addition, CMSs such as Drupal which allow you to execute dynamic PHP also warn you not to do so. You can turn off the facility, as well. I would say that all your PHP should be in files. And you should turn off perms for "other". The files should be owned by you, and the webserver should run as you (meaning your user), not as "www-data" or whatever. That prevents nice and easy updates, but it's better.
Well, here's a route to that: If you can somehow manage to send messages to the controller as the admin, then:
1. let's say you're running a PHP CMS, as many/most websites are.
2. many PHP CMS's allow you to execute arbitrary PHP (if you have appropriate perms).
3. the DB username/password is normally contained in a PHP file
4. if you can execute arbitrary PHP, you can probably already execute arbitrary SQL using the CMS APIs. Or you can read the DB username/password and use that, or send it off somewhere.
OK, they might have taught you that in college. But they didn't necessarily teach everybody that.
In any case, every there's a post about college on /., most posters come out to say that college isn't about learning the specifics of development (like frameworks, SCM, etc.). It's about learning the theory of computer science. Learning minutiae is for trade school.
If that's the case, then people who studied the science of computing would have no clue about SQL injection. There's really no place you'd be able to learn, except if 1) you happen to get a good mentor at your first job, or 2) you happen to read about it on the Interwebs.
Translation: You want bespoke (nuclear powerplant-level) security at mass-market prices.
Seriously, who pays this guy (and the rest of the Gnome crew) to "create art"?
This. What exactly is it that you want to see with this much resolution?
The thin wires that hold props and whatnot in place for movies? Look, it's supposed to be a suspension of belief. That's what's required for a work of fiction. Too high of a resolution ruins the effect. Not to mention who wants to see every pore of every actor's face?
Even for documentaries: What's the point? Do you require this much resolution IRL? I'd venture to guess if you had an ultra-high resolution view of your pillow (including dust mites) you'd probably not be able to sleep.
Latest? Actually, if you want to be the "latest" you should send your email at exactly 8:01 AM.
One of the things that sort of nutty about email is the earlier emails get read last, just because of the sorting.
If you send a series of emails in which you patiently explain a bunch of things, and then in the following emails, you go into detail on some of those subjects, your readers will get the detail emails first (in their sorting).
Reading those will make them go "Huh?".
People aren't necessarily carrying around customer cc numbers on their phones.
Rather, when you blur the lines of work and home, you make it easier for attackers to get in an in to the corporate network, where they they proceed to grab what they want to.
How do you propose to keep company data private?
If you have a work-issued machine, the lines are clear: Work stuff is on the work phone/laptop/whatever, and it's password protected. Home stuff is on your device.
If it's BYOD, and Junior wants to play games on you iPhone, you just handed him a device that has your work stuff on it. If it's your own device, it's much more likely to be less protected and touched by more hands than a work device.
All those stories on the /. frontpage about credit card numbers stolen? They start with little leaks, and then the attacker wiggles his way in.
BYOD is a disaster.
And I believe in that.
One thing, though: It's generally considered that Apple pays workers more than the going rate. And they have pretty good benefits in Apple Stores, too. Finally, they give them a good deal of ego boost ("respect").
Still, that didn't prevent all these shenanigans.
Basically: "Trust, but verify", and I'm asking about the verify part.
Anybody want to share any tips? What are the checks & balances that can help detect problems such as those in the article?
>Why is income-based pricing a boogeyman now?
The reason, of course, is people are always ready to "soak the rich" when it's someone else getting wet. When the "rich" include them, then they suddenly think everyone should pay equally.
They charge an aircon fee? In some parts of Canada, I'd guess you can do without A/C.
When I hit CtrlAltF1, both laptop and external monitors go to the terminal (Ubuntu on a late model Lenovo with Intel graphics.) What are you using?