Yes. It would. However if the device is allowed to roam on other networks (such as a laptop an employee can take home) this can cause issues with various key pinning solutions, and possibly also with HSTS.
Unfortunately the days that it was easy to intercept TLS traffic by simply trusting your own CA are slowly going the way to the dodo because of CA abuse that has happened in the past.
This mindset of "we just need to protect at the borders; this protects endpoints" is wrong. While it provides some protection, there are so many other avenues of infection or acquiring malware that trying to equate TLS with making things simpler to hide just seems incredible of an assertion to make. These days you absolutely need to make sure that endpoint protection is just as strong, if not stronger than what you deploy on the borders of your network.
As more corporations allow bring your own device to save costs, and give employees laptops, you can no longer trust in just filtering at the border, because the devices can move, people bring in thumb drives, and other avenues for getting malware. TLS or no TLS, I have a feeling that most HTTP intercepting proxies would not have caught newer malware in ads even if configured to do so, simply by the nature that by the time there is a signature available for it, it is generally already too late and people will have been infected.
1) Can someone make it very clear just what the relationship of OpenIndiana to IllumOS is?
IllumOS is the base operating system, much like Linux, except that it comes with a full user land too.
2) How exactly does NexentaOS fit in? And NexentaStor? And StormOS? And SmartOS?
Those are all distributions of Illumos. All of them contribute to Illumos and build on top of it by providing their own packages/packaging systems and system that run on top of Illumos. Think of them like Ubuntu/CentOS/Debian to Linux.
3) At least several of those I mentioned are open source/free, and I believe there are others. Why so many forks? Which one looks like the leader?
Illumos is the "leader", and the base operating system that all of those products use (AFAIK). Each of them have different options/features. NexentaStor for example is built to be a ZFS based storage appliance solution, SmartOS is for datacenters/virtualisation and things of that nature. They each bring something unique to the table. Each of them is built by a different company that offers different types of support.
The product formerly (freely) available as OpenSolaris had a lot to recommend it. FreeBSD has been playing catchup and has come a long way, but is still lacking in various ways. Linux is an excellent product, but glaring probems exist in the direction it is going, and I don't see it ever coming close to matching the OpenSolaris feature set in my lifetime.
OpenSolaris is still around, just with the name changed to OpenIndiana. OpenSolaris after a pkg mirror location upgrade was readily renamed to OpenIndiana, and this was the upgrade path that I took personally.
but I as a developer sure do notice. The biggest issue I keep running into (developing backend software for my companies frontend software) is that testing on a mix of devices means learning the quirks for every single manufacturers user interface that they have bolted on top of Android. We've also had some weird issues based upon the Android version installed, across two devices with the same Android version number (4.0 for example) with the carrier/device manufacturers changes we have a bug on one but not the other.
This is highly annoying.
One issue that Android users hail as the greatest thing since sliced bread (alternate keyboards) actually meant having to write work-arounds because some keyboard implementations were simply broken, or actually caused issues with entering text in certain situations. An alternate keyboard shouldn't be able to have that sort of an effect!
Fragmentation is real, and it is an issue. Consumers don't notice because they only use a single device, developers and power users that may switch more often than the average user will notice and it is an issue.
You seem to have lost the ability to read. No, I was specifically stating 100 mA, that is the max any USB device is allowed to pull from any charger or device it is plugged into, UNLESS it asks the host for more OR the D+/D- lines have specific voltages/are shorted.
Apple requires specific voltages precisely because the standard of just shorting the D+/D- lines don't provide enough information. Just how much current should an iPad attempt to pull from a charger that has the D+/D- lines tied together? It can be unsafe for a device to pull more amps than a power supply can provide for a variety of different reasons, especially with switch mode power supplies.
---
As for your last point, while you and I may agree on one thing, that it is is a vulnerability and it should get fixed, it isn't a classic vulnerability. It doesn't take advantage of bad coding practices, there is no buffer overrun, or null terminated string vulnerability which is what you were referring to in your original post.
The biggest problem I have with my Touchpad (I own one too) is that when inductively charging it won't charge nearly as fast, and I've had plenty of times where it has been sitting on the inductive charger for a day or so, and I pick it up and 20 minutes later the battery is dead. Whereas charging it over USB seems to always charge it fully and properly.
Why does this guy keep getting modded up to informative? There is no Apple DRM, there is no blocking of 3rd party chargers. Apple devices while charging look for certain voltages on the D+/D- lines, there is absolutely no communication between the device and the charger. The only reason there is a requirement for certain voltages on the D+/D- lines is so that the Apple device knows it is safe to pull a certain amount of amperage from the charger...
This is so completely wrong that I don't even know where to begin.
1. Apple hasn't put DRM in their chargers 2. Apple devices look for a certain voltage on the D+/D- traces to know whether they can charge at 100 mA, 500 mA, or more, specifically the iPad can draw more power 3. Apple devices are also USB devices, when they connect to a USB host (such as the BeagleBone) they communicate using standard USB, that is the only ID string that gets sent back, along with a request for at least 500 mA of power to be provided by the host. 4. This doesn't actually use any specific vulnerability, rather it uses the fact that when you connect an iOS device you can using a provisioning profile side-load apps onto the phone. This is generally done during development or for example in corporate settings. These same provisioning profiles can be used to disable certain features, or set up emails accounts, wifi passwords, and all that fun stuff, you know to provision a device in a corporate scenario.
It's a shame that your comment got voted up as informative when it contains so much mis-information.
I am wondering how this stacks up to a project like WebKit/Blink, as well as seeing that project against the original KHTML. Sure it is a renderer/HTML layout/JavaScript engine only, and won't contain the browser chrome like Firefox, but I think it would be interesting to look at.
Many people have also suggested that WebKit is easier to embed into various different environments (more so than Gecko) and that it has been able to evolve faster mainly due to the code base being cleaner, and I wonder if this holds true when looking at it from a complexity standpoint, or is it more complex but simply laid out better and in a way that is easier to understand?
Even if Windows were running on bare hardware I could play tricks with the clock, I could hide memory from any program that Blizzard could come up with to attempt to scan regions of memory, I still could pull all of the tricks you just mentioned. How? Using good ol' virtualisation extensions that exist within processors.
Not only that but I own the hardware, I have physical access to the hardware, there is no good way for any program to insert itself at a higher level. I control the boot process so I get to choose where the OS is loaded, I get to change the way it works and interacts. Writing kernel level modules that tamper with time like you are suggesting that would be simple with Wine are entirely possible using straight Windows as well.
Thats the biggest problem, Blizzard doesn't own, they don't manufacture and they can't guarantee that no-one has tampered with the hardware. There comes a point where the software is running on top of the hardware and it has to trust that the hardware is not being malicious. This is how cable box hacks, and satellite box hacks used to work.
Blizzard can write a root kit all they want, if people want to cheat and if there is enough incentive to do so people will find ways to defeat the rootkits behaviour and cheat. Until everything is sent over an RDP like protocol and no code executes client side this is a problem that is going to exist for the foreseeable future.
This issue has been going on for a long time, and each time a BSD developer asks to see solid docs so that he/she can port the API to be used on FreeBSD they get a bunch of incomplete specs that are absolute shit.
If the device/board already has 120v coming in on it, then having a device keep its time from AC is rather simple. One zener diode, a resistor and an open pin on a microcontroller are all that are required.
Take a look at some zero cross detection circuits, they are extremely simple, and the parts for them are cheaper than for a crystal that is accurate at time keeping when the power companies keep the 60 Hz in sync.
Whisper Systems is an US based company that has never provided user data to Egypts government, nor has it allowed them to send messages through their system. You are thinking about Vodafone which was forced to do so by the government.
I am probably missing something funny here. Egypt did not remove their top-level domain entries, that wouldn't accomplish anything. Egypt stopped announcing their ASN, and thus all of the routes for their assigned IP addresses.
Removing just the top-level domain would still allow people to use IP addresses to communicate over the network, and would still allow outgoing traffic as well.
You can do NAT on an IPv6 connection the same way you are doing NAT on IPv4. Also, instead of using NAT to protect resources you should be using a border firewall that has the same rules for IPv6 as you have for your IPv4. That way from the outside even if they scan one of your IP addresses it still has the proper ports closed.
Assign internal IPv6 addresses to your network, and then NAT on those. Simple.
Whatever gateway you have that is doing route advertisements for IPv6 is still the primary location for firewalling, and is still your single point in and out of your network.
What functionality are we BSD users ...
on
Xfce 4.8 Released
·
· Score: 2, Insightful
What functionality are we BSD users going to be missing? It didn't really say in the article at all other than that apparently there is a lot of Linux only stuff out there in the open source world. As a developer I am saddened by this fact, that what I have available for use on Linux won't work the same on FreeBSD for example making my life as a developer and porter much harder.
Where does the problem lie? Is it in the library developers or in the OS developers? What can be done to change the situation? Where are some places we can start looking?
I drive a manual car, and as such my hands are almost NEVER both on my steering wheel. Should my GPS still be disabled when there is a passenger in the car? How is it supposed to know that there is a passenger in the car since I now don't have both hands on the steering wheel?
And don't tell me that my stick shift is part of the problem. I am more attentive to the road for one particular reason, I can't just have the car take care of shifting for me, I have to be involved in what my car is doing, how fast I am going, what the RPM's are of my engine so I don't blow it up, because of that I need to pay attention to the road, I need to watch other cars to know to slow down, when I can shift into a higher gear, when I need to down shift, I need to watch the road for any inclination so I can appropriately shift into the various different gears.
Because of driving a stick shift I would say I am better prepared to multi tasking within my car and still operating it safely more so than others.
Something like http://www.tinyclr.com/ is actually pretty cool, having used it, yes the 72 Mhz chip feels a little slow compared to using it more directly using C.
Microsoft has also updated many of the libraries, so it is easier to do various different tasks at the same time, however there are still a lot of steps involved in writing code for something like the FEZ domino, I could definitely understand that it is harder, yet at the same time Visual Studio is an absolutely awesome development environment that is not yet matched on Mac OS X or Linux.
Depends on the engine. My engine will not provide enough power while in idle so that I stay in the same place on a steep incline. I use the handbrake. Pull up the handbrake, move foot from brake pedal to gas pedal, slowly let the clutch up, give it a little gas and when I feel it starting to move let go of the hand brake.
Holding programmers accountable for their coding errors should happen inside of the corporation as they are working on the project. I don't remember which company had this, but if a developer broke the build it failed to pass a test a lava lamp at their cubicle would turn on, and until the developer fixed the build the lava lamp would stay on, which generally meant you had a certain amount of time to fix the issue before it would actually start bubbling. This way there is an incentive not to break the build, and a bit of competition between the various programmers to have the least amount of bugs or build breakages.
Having programmers imagine every way that their program may be attacked is impossible. There will always be new attacks that take advantage of that one that the programmer had not thought of. Just like the security systems that are in place at airports around the world. If the good guys could come up with every single scenario that an attacker could take airports would be much safer, as every single scenario had already been thought about.
I agree with you, don't put all the blame on me as a programmer.
Slashdot Mirror
Yes. It would. However if the device is allowed to roam on other networks (such as a laptop an employee can take home) this can cause issues with various key pinning solutions, and possibly also with HSTS.
Unfortunately the days that it was easy to intercept TLS traffic by simply trusting your own CA are slowly going the way to the dodo because of CA abuse that has happened in the past.
This mindset of "we just need to protect at the borders; this protects endpoints" is wrong. While it provides some protection, there are so many other avenues of infection or acquiring malware that trying to equate TLS with making things simpler to hide just seems incredible of an assertion to make. These days you absolutely need to make sure that endpoint protection is just as strong, if not stronger than what you deploy on the borders of your network.
As more corporations allow bring your own device to save costs, and give employees laptops, you can no longer trust in just filtering at the border, because the devices can move, people bring in thumb drives, and other avenues for getting malware. TLS or no TLS, I have a feeling that most HTTP intercepting proxies would not have caught newer malware in ads even if configured to do so, simply by the nature that by the time there is a signature available for it, it is generally already too late and people will have been infected.
1) Can someone make it very clear just what the relationship of OpenIndiana to IllumOS is?
IllumOS is the base operating system, much like Linux, except that it comes with a full user land too.
2) How exactly does NexentaOS fit in? And NexentaStor? And StormOS? And SmartOS?
Those are all distributions of Illumos. All of them contribute to Illumos and build on top of it by providing their own packages/packaging systems and system that run on top of Illumos. Think of them like Ubuntu/CentOS/Debian to Linux.
3) At least several of those I mentioned are open source/free, and I believe there are others. Why so many forks? Which one looks like the leader?
Illumos is the "leader", and the base operating system that all of those products use (AFAIK). Each of them have different options/features. NexentaStor for example is built to be a ZFS based storage appliance solution, SmartOS is for datacenters/virtualisation and things of that nature. They each bring something unique to the table. Each of them is built by a different company that offers different types of support.
The product formerly (freely) available as OpenSolaris had a lot to recommend it. FreeBSD has been playing catchup and has come a long way, but is still lacking in various ways. Linux is an excellent product, but glaring probems exist in the direction it is going, and I don't see it ever coming close to matching the OpenSolaris feature set in my lifetime.
OpenSolaris is still around, just with the name changed to OpenIndiana. OpenSolaris after a pkg mirror location upgrade was readily renamed to OpenIndiana, and this was the upgrade path that I took personally.
Hope this helps clarify things a little.
but I as a developer sure do notice. The biggest issue I keep running into (developing backend software for my companies frontend software) is that testing on a mix of devices means learning the quirks for every single manufacturers user interface that they have bolted on top of Android. We've also had some weird issues based upon the Android version installed, across two devices with the same Android version number (4.0 for example) with the carrier/device manufacturers changes we have a bug on one but not the other.
This is highly annoying.
One issue that Android users hail as the greatest thing since sliced bread (alternate keyboards) actually meant having to write work-arounds because some keyboard implementations were simply broken, or actually caused issues with entering text in certain situations. An alternate keyboard shouldn't be able to have that sort of an effect!
Fragmentation is real, and it is an issue. Consumers don't notice because they only use a single device, developers and power users that may switch more often than the average user will notice and it is an issue.
You seem to have lost the ability to read. No, I was specifically stating 100 mA, that is the max any USB device is allowed to pull from any charger or device it is plugged into, UNLESS it asks the host for more OR the D+/D- lines have specific voltages/are shorted.
Apple requires specific voltages precisely because the standard of just shorting the D+/D- lines don't provide enough information. Just how much current should an iPad attempt to pull from a charger that has the D+/D- lines tied together? It can be unsafe for a device to pull more amps than a power supply can provide for a variety of different reasons, especially with switch mode power supplies.
---
As for your last point, while you and I may agree on one thing, that it is is a vulnerability and it should get fixed, it isn't a classic vulnerability. It doesn't take advantage of bad coding practices, there is no buffer overrun, or null terminated string vulnerability which is what you were referring to in your original post.
The biggest problem I have with my Touchpad (I own one too) is that when inductively charging it won't charge nearly as fast, and I've had plenty of times where it has been sitting on the inductive charger for a day or so, and I pick it up and 20 minutes later the battery is dead. Whereas charging it over USB seems to always charge it fully and properly.
Why does this guy keep getting modded up to informative? There is no Apple DRM, there is no blocking of 3rd party chargers. Apple devices while charging look for certain voltages on the D+/D- lines, there is absolutely no communication between the device and the charger. The only reason there is a requirement for certain voltages on the D+/D- lines is so that the Apple device knows it is safe to pull a certain amount of amperage from the charger...
This is so completely wrong that I don't even know where to begin.
1. Apple hasn't put DRM in their chargers
2. Apple devices look for a certain voltage on the D+/D- traces to know whether they can charge at 100 mA, 500 mA, or more, specifically the iPad can draw more power
3. Apple devices are also USB devices, when they connect to a USB host (such as the BeagleBone) they communicate using standard USB, that is the only ID string that gets sent back, along with a request for at least 500 mA of power to be provided by the host.
4. This doesn't actually use any specific vulnerability, rather it uses the fact that when you connect an iOS device you can using a provisioning profile side-load apps onto the phone. This is generally done during development or for example in corporate settings. These same provisioning profiles can be used to disable certain features, or set up emails accounts, wifi passwords, and all that fun stuff, you know to provision a device in a corporate scenario.
It's a shame that your comment got voted up as informative when it contains so much mis-information.
I am wondering how this stacks up to a project like WebKit/Blink, as well as seeing that project against the original KHTML. Sure it is a renderer/HTML layout/JavaScript engine only, and won't contain the browser chrome like Firefox, but I think it would be interesting to look at.
Many people have also suggested that WebKit is easier to embed into various different environments (more so than Gecko) and that it has been able to evolve faster mainly due to the code base being cleaner, and I wonder if this holds true when looking at it from a complexity standpoint, or is it more complex but simply laid out better and in a way that is easier to understand?
You have clients ... charge a little more and absorb the cost of new hardware. What's so hard about that?
Even if Windows were running on bare hardware I could play tricks with the clock, I could hide memory from any program that Blizzard could come up with to attempt to scan regions of memory, I still could pull all of the tricks you just mentioned. How? Using good ol' virtualisation extensions that exist within processors.
Not only that but I own the hardware, I have physical access to the hardware, there is no good way for any program to insert itself at a higher level. I control the boot process so I get to choose where the OS is loaded, I get to change the way it works and interacts. Writing kernel level modules that tamper with time like you are suggesting that would be simple with Wine are entirely possible using straight Windows as well.
Thats the biggest problem, Blizzard doesn't own, they don't manufacture and they can't guarantee that no-one has tampered with the hardware. There comes a point where the software is running on top of the hardware and it has to trust that the hardware is not being malicious. This is how cable box hacks, and satellite box hacks used to work.
Blizzard can write a root kit all they want, if people want to cheat and if there is enough incentive to do so people will find ways to defeat the rootkits behaviour and cheat. Until everything is sent over an RDP like protocol and no code executes client side this is a problem that is going to exist for the foreseeable future.
This issue has been going on for a long time, and each time a BSD developer asks to see solid docs so that he/she can port the API to be used on FreeBSD they get a bunch of incomplete specs that are absolute shit.
http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors#c14587
Warner Losh asking for good specs to implement udev on top of devd which has done the things that udev now does for years.
If the device/board already has 120v coming in on it, then having a device keep its time from AC is rather simple. One zener diode, a resistor and an open pin on a microcontroller are all that are required.
Take a look at some zero cross detection circuits, they are extremely simple, and the parts for them are cheaper than for a crystal that is accurate at time keeping when the power companies keep the 60 Hz in sync.
I've got a MacBook Pro. It's going on year 5 at the moment. No issues with the hard drive.
Whisper Systems is an US based company that has never provided user data to Egypts government, nor has it allowed them to send messages through their system. You are thinking about Vodafone which was forced to do so by the government.
I am probably missing something funny here. Egypt did not remove their top-level domain entries, that wouldn't accomplish anything. Egypt stopped announcing their ASN, and thus all of the routes for their assigned IP addresses.
Removing just the top-level domain would still allow people to use IP addresses to communicate over the network, and would still allow outgoing traffic as well.
You can do NAT on an IPv6 connection the same way you are doing NAT on IPv4. Also, instead of using NAT to protect resources you should be using a border firewall that has the same rules for IPv6 as you have for your IPv4. That way from the outside even if they scan one of your IP addresses it still has the proper ports closed.
Assign internal IPv6 addresses to your network, and then NAT on those. Simple.
Whatever gateway you have that is doing route advertisements for IPv6 is still the primary location for firewalling, and is still your single point in and out of your network.
What functionality are we BSD users going to be missing? It didn't really say in the article at all other than that apparently there is a lot of Linux only stuff out there in the open source world. As a developer I am saddened by this fact, that what I have available for use on Linux won't work the same on FreeBSD for example making my life as a developer and porter much harder.
Where does the problem lie? Is it in the library developers or in the OS developers? What can be done to change the situation? Where are some places we can start looking?
I drive a manual car, and as such my hands are almost NEVER both on my steering wheel. Should my GPS still be disabled when there is a passenger in the car? How is it supposed to know that there is a passenger in the car since I now don't have both hands on the steering wheel?
And don't tell me that my stick shift is part of the problem. I am more attentive to the road for one particular reason, I can't just have the car take care of shifting for me, I have to be involved in what my car is doing, how fast I am going, what the RPM's are of my engine so I don't blow it up, because of that I need to pay attention to the road, I need to watch other cars to know to slow down, when I can shift into a higher gear, when I need to down shift, I need to watch the road for any inclination so I can appropriately shift into the various different gears.
Because of driving a stick shift I would say I am better prepared to multi tasking within my car and still operating it safely more so than others.
Why doesn't this have more points? I wish I had mod points just to set the record straight!
Good luck to you guys!
Something like http://www.tinyclr.com/ is actually pretty cool, having used it, yes the 72 Mhz chip feels a little slow compared to using it more directly using C.
Microsoft has also updated many of the libraries, so it is easier to do various different tasks at the same time, however there are still a lot of steps involved in writing code for something like the FEZ domino, I could definitely understand that it is harder, yet at the same time Visual Studio is an absolutely awesome development environment that is not yet matched on Mac OS X or Linux.
No, and the amateurs that are playing with the Arduino and Basic stamp are not going to use .NET either ...
Depends on the engine. My engine will not provide enough power while in idle so that I stay in the same place on a steep incline. I use the handbrake. Pull up the handbrake, move foot from brake pedal to gas pedal, slowly let the clutch up, give it a little gas and when I feel it starting to move let go of the hand brake.
Holding programmers accountable for their coding errors should happen inside of the corporation as they are working on the project. I don't remember which company had this, but if a developer broke the build it failed to pass a test a lava lamp at their cubicle would turn on, and until the developer fixed the build the lava lamp would stay on, which generally meant you had a certain amount of time to fix the issue before it would actually start bubbling. This way there is an incentive not to break the build, and a bit of competition between the various programmers to have the least amount of bugs or build breakages.
Having programmers imagine every way that their program may be attacked is impossible. There will always be new attacks that take advantage of that one that the programmer had not thought of. Just like the security systems that are in place at airports around the world. If the good guys could come up with every single scenario that an attacker could take airports would be much safer, as every single scenario had already been thought about.
I agree with you, don't put all the blame on me as a programmer.
Oh, if I had mod points, you sir would have them!
I humbly stand corrected.