So... you want to be able to have a single number ring through to 10 alternate numbers at the same time? That makes no sense!
No, actually it makes perfect sense. This is implemented in all traditional PABXes - e.g. someone phones your business and it rings several phones. Whichever is picked up first gets the call. Or another popular implementation of the same idea is hunt groups - i.e. a call comes in and it rings for a short time on one phone, if it isn't answered it rings another phone instead.
Re:Although this seems "reasonable" in light of th
on
Google Delists BMW-Germany
·
· Score: 2, Insightful
What I did say was that google has an imperfect algorithm, and along with punishment for trying to get around that imperfect algorithm, creates a situation where they dictate the rules, and the punishment for not following them.
Alternatively, consider the rules and the punishment to be part of that algorithm. Just because they aren't handled automatically doesn't make them any less relevent as part of the algorithm.
It's this "follow our rules or be punished" attitude that's disturbing.
It's no different to any other advertising medium.
Want to advertise on billboards? The billboard owner and the ASA dictate the sort of content you're allowed to put up. If you piss off the public then it's also likely to come back to bite you in the arse when they complain to either.
In both these cases the rules are good for the consumer - they punish you for putting up misleading or offensive content.
but there is nothing wrong with reasonable use of DRM for protecting intellectual property in a manner consistent with appropriate precedents and law.
The problem here is that many laws are written by the very corporations who are using DRM. At the moment I have the ability to ignore a law (and risk the consequences) if I believe it to be a morally bad law. DRM removes that ability and forces my moral compass to be aligned with the moral corruptness of the lawmakers who were bought out by the content producers.
Infact this all rather reminds me of a police state.
I do not understand people that are totally anti-Rights-management.
Because DRM is used in a way that is _too_ restrictive. i.e.: 1. Why shouldn't I be allowed to import a DVD from another region? Maybe it's never going to be available in my region, or maybe it's a lot cheaper if I import it. Yeah, the manufacturers have problems with me buying it from a cheaper region but they don't hesitate to make people redundent because they can employ people to do the same work cheaper elsewhere. If the manufacturers want to exploit the global economy, why do they have the right to prevent their customers from doing the same? 2. Why shouldn't I be allowed to play a DVD using FOSS software? IMHO a mainstream distribution format should not require me to buy specific hardware or software in order to read it - I have legitimately bought the media and a licence to the content, I shouldn't have to pay more money to use it. 3. Even if DRM is only used to prevent you breaking the laws, I worry about this since many people legitimately believe that a lot of laws are bad laws - people should be allowed (to some extent) to be able to use their own moral compass to decide what's right. A good example is the broadcast flag - why should I be prevented from making a video recorder to allow me to time-shift TV shows for my own use? Recording TV shows and then watching them a few hours later doesn't create any adverse effects for anyone so from what I can see the broadcast flag will simply restrict what I can do with the content for no good reason - currently I can ignore such bad laws but if it's actually enforced through technological means I can nolonger make a moral choice for myself.
This is really about trust - why should I trust someone to get the restrictions placed on content right?
The trust issue also applies to things like software signing: being able to lock a machine down so it can only run trusted software on the surface looks attractive - no more malware. But how do I trust the certification authority? e.g. if a machine will only run software that Microsoft certifies as trusted then I have these problems: 1. Why should I trust that MS's definition of "trusted" is the same as mine. For example, Windows Media Player and IE7 both "phone home" - presumably MS thinks that's trustworthy behaviour but I certainly don't. 2. What are the legal implications if MS accidentally signs some malware? If there's no penalty then it seems software signing is useless. 3. Why should I trust that MS won't use software signing to stop 3rd parties producing competing software - what happens when they refuse to sign OpenOffice for example?
Essentially, a certification authority needs to be trusted - what do I base that trust on? In my experience, large companies and governments are both untrustworthy (from the consumer's point of view).
I mean he lists workarounds as 'Firefox'; which just shows how little he understands the security field which he claims to work in (A workaround should be a way to fix or bypass the bug, not a blind pointer at some random other product, even the Linux Security guys know that).
In most cases, yes - a workaround should allow you to continue using your current product. However, in some cases the affected product is considered so fundamentally flawed that alternative products must be considered. Even CERT has (at least once) recommended people replace IE with a different browser in light of a serious security hole.
This is generally the result of lazyness in bugfixing meaning that even though the hole has been known about for a while there is still no patch in the foreseeable future. The answer is to be more proactive - fix bugs as soon as they are found rather than waiting until they are exploited in the wild before starting to engineer a fix. (There are numerous examples of IE security holes that had been known about for many months and a patch was only implemented after exploits started to be widely used in the wild).
most betas are at least close enough to finish that the programmers are looking for the obscure bugs
What surprised me about beta 1 was that they hadn't even finished implementing features that were already on the final product's feature list. Actually, it seemed that they hadn't actually finished deciding what was going on the feature list.
Most people would consider that development stage to be alpha - beta is where you have finished implementing the feature list and you are now after feedback from the customers on bugs, user interface and what extra features they think need to be implemented which weren't on the feature list. I.e. a beta release should fulfill the original specification, albeit still needing some bugfixes.
Uhh. How does it make any difference what company makes a firewall? Code is code, no matter who writes it.
Because Windows is closed source - 3rd parties can't add functionality to existing code, they have to stick to using the hooks provided whereas Microsoft could add functionality right into the stack since they have acces to the source.
Have you any idea how network code actually works?
Yes, actually...
I don't actually have to "bind" to any specific interface in the first place. I just create a socket() -- not bound to any specific interface.
When creating a receiving socket, you can either choose to bind to a specific IP address or you can bind to 0.0.0.0 which essentially binds to all local IP addresses. So the behaviour here is obvious - a bind() call to a specific IP address would be disallowed if it wasn't authorised and a bind() call to 0.0.0.0 would result in the socket only being bound to the authorised IP addresses. Look at the bind(2) man page for more details about binding sockets.
You can send packets without binding first but again, you can make the authorisation check during the connect(2) or sendto(2) call rather than waiting until the packet has gone most of the way through the stack before blocking it.
By the way, as a secondary point, I could imagine a lot of poorly-written applications, assuming that you can just socket(), and get a socket without doing any form of error checking would simply fall over on startup
I would say that this is exactly the sort of software that would contain the most security holes and so preventing it from starting would be a Good Thing. For another reason why making these sorts of bugs obvious is that there are legitimate reasons for the call failing (for example, if you didn't have an IP stack installed)
Finally, putting the firewall in the operating system
I never said that the OS was the wrong place to put it (infact, if anything my idea is more tightly bound to the OS since it's embedded in the IP stack rather than being an external application which hooks at certain points).
and who is going to convince every single application developer to modify their applications so that such a task would be possible?
I suspect providing the framework and having the services that are shipped as standard use it would be a good start. Who convinced the developers to use the "add/remove programs" framework, and yet most (but not all) applications do. I'm not that familiar with windows, but the last time I had to endure Win2k Advanced Server I couldn't actually see a way of telling any of the standard services not to bind to the external NIC - this is something that could be added to the services configuration interface (as well as enable/disable a service you can have tick-boxes telling it what NICs to bind to).
This is available under Linux and Mac OS X with the relatively rough lsof application.
FWIW, "netstat -apn" (under Linux) gives you a nicer output showing what's going on on the network (including unix-domain) side.
A NAT router is not meant to be used as a firewall. It can be used as a line of obscurity, but that's about it.
Errm... who mentioned NAT? The thread was about firewalls: the complaint was made that a firewall needs configuration to allow the right protocols and the "solution" presented was to use UPnP (which is only 1 stage better than just shutting down the damned firewall)
You should really have a final line of defense in a host-level software firewall.
Now I kind of understand how these are built by 3rd parties (since they can't directly modify the IP stack) but I don't understand why Microsoft (who _can_ hack the IP stack) produced a personal firewall. What's the point in letting some malware bind to a NIC and send traffic and then go to the effort of catching that traffic between the IP stack and the wire? It would seem a far better idea to just prevent the unauthorised software from binding to the NIC in the first place, which would prevent it from even being able to generate the unauthorised packets in the first place.
Whilest I agree that firewalls are a useful feature, I question the idea of treating them as a "first line" defense. IMHO the first line of defense is properly configured services - i.e. make sure they bind to the correct NICs. If a service doesn't want to be accessible from the outside world then just don't tell it to bind to the external NIC. The firewall should be treated as a fail-safe incase you screw up and bind a service to the external port (or some malware gets on the machine). It seems that usually firewalls are used as the _only_ line of defense, and in that case there is really no advantage in using a firewall over properly configuring the services since you have no fail-safe to cover you in the event you screw up the firewall config.
A system with all the services bound to the external NIC and a firewall stopping the malicious traffic getting to those services is no more secure than a system with no firewall and the services only bound to the relevent NIC.
I suspect what is needed is simply a unified UI to configure which services are bound where in a similar way to the unified firewall configurators which allow you to open and close any ports from a single UI.
Which Tier 1 routers do you have enable on? Because the ones I've worked on aren't configured for v6
Off the top of my head, Teleglobe carry native IPv6 traffic across their tier-1 network.
At least in North America, v6 and v4 are routed discretely.
IPv4 and IPv6 are discrete protocols - you have to route them discretely. In any case, noone in this thread ever mentioned whether they expected IPv4 and IPv6 to be routed separately or not - you said "A Tier1 provider can't just throw things in their configs and hope everything's OK." which seems redundent - of course they don't just "throw things in their configs and hope", but this doesn't (and hasn't) prevented them from providing native IPv6 tier-1 networks. Just because something's not easy doesn't make it not possible - by your arguement the tier-1 providers would never make *any* changes to their networks for fear of breaking them, but with sufficient testing it's not a problem.
You want to keep spouting off about that which you do not understand? Or are we done here?
I'm not spouting off about things I don't understand - I've worked with both IPv4 and IPv6 networks extensively for years. On the other hand, you haven't yet explained the basis for your crazy arguement claiming that you can't do 6to4 (a system that uses the 6in4 protocol that runs ontop of IPv4) without your ISP implementing a native IPv6 network. You might as well be saying "you can't use GRE without special GRE support from your ISP" which is equally untrue - the ISP only needs to know about the IPv4 level, none of the higher protocols (TCP,UDP, GRE, 6in4, etc). For the record, I have been running 6to4 with no problems for some time with no support on the ISP side.
IPv4 is running out of addresses because early-adopters took huge blocks of space and won't give those addresses up.
Not really - yeah there are a few class A's around but they're not going to make a lot of difference in the grand scheme of things, we still don't have anough addresses. Claiming them back would only buy us a couple more years.
So NAT comes along and provides some relief. But instead of doing it the right way, NATted addresses don't work as a global address.
Uh, how would NAT even allow global addressing? NAT inherrently means you are _destroying_ the original addressing data, making it impossible for your address to be global.
People are just now getting used to the 4-octet addresses and won't be at all comfortable with a switch to longer, harder-to-remember ones.
Most people using the internet never see an IPv4 address anyway - thats what DNS is for. I agree that in certain cases, easy to remember addresses are a Good Thing but to the majority of people I think it's a moot point (and in most of these cases dynamic DNS updates can be used to remove the need to know the IP address)
First of all, reserved blocks of IPv4 address space would be released.
This would involve upgrading IP stacks which are hard-coded to disallow the use of the reserved blocks. If you have to upgrade all the IP stacks you may as well replace them with a better protocol (remember that IPv6 isn't just about more addresses).
Then, NAT2 can be put to good use. NAT2 would allow for scope-resolved addresses.
What you're talking about is essentially a reduced form of source-routing - an idea that is almost universally considered a security problem since crackers can route around a firewall. It also requires a major protocol stack rewrite so bang goes the idea of maintaining compatability - may as well just use IPv6.
The addresses only get long when you build a deep network.
There are significant performance issues with having variable-length addresses, and your idea involves everyone having some idea what the route is to your network - network's aren't nice neat hiararchies (and that's good - hiararchies have poor performance and resilliance).
In short, on the surface your idea looks attractive, but in practice it is unworkable because it would lead to poor performance, resilliance and security.
Except noone sane would enable UPnP on their firewall since it's a major security hole. What's the point in a firewall when malware can turn the damned thing off?
The 'mobile devices' argument is total bullshit. The only devices that need public IPs are servers.
You are indeed correct - only servers need global scope IP addresses.... Oh wait, in peer to peer networking everyone is both server and client so everyone needs a global scope IP.
The 'mobile devices' arguement is very valid - if you have a mobile SIP phone it needs to be globally addressable (ok, there are work arounds for this problem but they're not nice). How do you think 2 SIP phones talk to eachother when they're both behind NATs? (the answer is they do NAT traversal using protocols like STUN and 3rd party servers which sucks since not only are you relying on a 3rd party but you're relying on the NAT doing what you predict which isn't always the case).
Similarly, when you start up bittorrent, you are starting a server on your machine and people need to be able to connect to it.
Hell, it's a potential security hole to give a non-server a public IP *at all*
No, I'm failing to see that - it's only a security hole if you didn't put a stateful firewall infront of it. The only reason this is seen as a non-issue when doing NAT is because NAT is inherently built ontop of a plain and simple stateful firewall (except usually not a well configured one - with most consumer grade NAT routers you can actually connect to the internal network if the ISP's router is misconfigured).
there is no legitimate reason for wanting to access a mobile phone remotely.
Yes... yes I can see that, there's no reason why a mobile phone should ever want to receive a phone call is there.
Also, ipv6 doesn't get rid of NAT.
Umm, yes it does - IPv6 RFCs _explicitly_ disallow translation of addresses by intermediate routers.
Really it isn't - it solves a large number of real-world problems which are becoming more important. For example, peer-to-peer applications such as SIP are difficult and unreliable without global addressing (and rely on external servers to help with NAT traversal). With a globally addressed protocol you can do true peer-to-peer without reliance on third parties.
doesnt play with legacy systems
Rubbish - if you can't get a connection over IPv6 you fall back to IPv4. If what you're trying to do isn't possible over IPv4 then frankly you would be no better off if IPv6 didn't exist.
even win2k support is flaky at best
Ah, what a wonderful arguement, "$technology is crap because $lazy_vendor doesn't support it". Here's news for you - IPv6 has been supported in BSD, Linux, MacOS-X and others for _years_. The Win2k IPv6 stack (which incidentally is a _technology preview_) was microsoft's first (half-arsed) attempt at catching up with the other systems which had had support for years. This is very reminicent of IPv4, which MS originally didn't support at all because they considered the Internet to be a "fad" that wasn't worth investing in. Back then you needed to use 3rd-party IPv4 stacks - did that make IPv4 a bad technology that would never be used in the real world?
all those routers and wifi boxes that best buy are selling
The lack of IPv6 support in budget routers is indeed a problem, although one that can be worked around by tunelling over IPv4 (which you have to do anyway if your ISP doesn't support IPv6 natively). Wifi boxes generally don't matter since they are usually just ethernet bridges - they don't know or care about what protocol you're using. The web interface on an access point is of course accessible only over IPv4 but this isn't a problem, noone's suggesting turning off IPv4 support yet.
most of the ISP's dont want it and dont support it let alone the users figure it out
I don't think that's particularly the case - many larger ISPs already support IPv6 natively. And anywhere you have a global IPv4 address you can tunnel IPv6 without the ISP's participation. The smaller ISPs will catch up once there is more IPv6 being used. This is simply an economics thing - nothing about them not "wanting" it, simply that they can't justify the cost until more people are using it.
Apart from that, NAT is also useful because of an inherent side effect, namely that a basic firewall comes "free" once your router has implemented NAT.
Rubbish - NAT is nothing to do with firewalling. To do NAT you basically take a stateful firewall and glue some extra functionality on top. The NAT bit doesn't add any security over just a plain stateful firewall and creates significant problems for all but the simplest of protocols since there is no (reasonable) way to inform the application of what it's address and ports are being translated to. This leads to peer-to-peer applications such as SIP having to use kludges like STUN, which don't work in all cases.
Far better to have global addressing (i.e. IPv6) and a stateful firewall than the horrible mess that is IPv4+NAT.
Personally, I'd rather have a written guide of some form to refer to when I implement IPv6
The bottom of http://sucs.org/wiki/ipv6 tells you how to configure 6to4 under Fedora Core 4. It's really just a case of setting a couple of options to "yes".
Or their routers aren't routing v6. Or their routers aren't configured for 6to4. Assumedly that would have to be done at the edge, as it would confound fast switching algorithms and push a core router over. Or the core routers between your ISP and your destination's ISP aren't configured for v6. Or your ISP is not getting v6 routes via BGP. Or another half-dozen reasons it won't work.
WTF are you talking about? You clearly need to go read up on IPv6 because what you just said is complete rubbish. Your ISP does _not_ need to know anything about 6to4. Every IPv4 address is assigned an IPv6/48 subnet and the traffic for that subnet is carried between the anycast 6to4 relay router (or other 6to4 gateway) and your 6to4 gateway entirely over IPv4.
I assume by "that would have to be done at the edge" you mean the edge of the ISP's network, which is incorrect - the encapsulation/de-encapsulation is done at the edge of *your* network. The ISP only sees IPv4 traffic.
They are not blocking traffic when they are not configured to support it.
If the ISP isn't "configured to support" 6to4 then they shouldn't be calling themselves an ISP since they aren't "configured to support" IPv4 in that case.
A Tier1 provider can't just throw things in their configs and hope everything's OK.
Well, firstly, most (all?) tier 1 providers already do _native_ IPv6 and secondly, why exactly do the tier 1 providers need to do any reconfiguration to carry 6to4 traffic?
Re:Fuzzing and Obfuscation
on
Mitnick on OSS
·
· Score: 1
Do you have any source code examples of this? I understand the concept but I still can't figure out how it works. When I return from a function I am popping information off the stack, so it doesn't matter what I overflow onto the stack while I'm in the function. It gets thrown away when I return.
Note that I'm not a cracker and not really done much theory here so I could be completely wrong, but I *think* the stack on x86 machines is implemented by stacking stuff starting from end rather than from the start (i.e. a buffer overflow will overwrite stuff that was previously pushed into the stack).
Can anyone confirm if this is true, and if it is, is there a good reason since it seems like the dangers of stack overflows could be greatly reduced by stacking from the start?
Re:Securing Open Source Code
on
Mitnick on OSS
·
· Score: 1
Well, not just interesting... Most of the people who work on OSS projects do so because they need the project to do something for them.
I think also the open bug-tracking systems using on many FOSS projects help - people are far more likely to report bugs if they get some feedback on them (i.e. you can see it's status in bugzilla, discuss the problem with the developers who are working on it, etc). Compare to most closed development where you send a bug report and it just vanishes - you have no clue if it's gone into some internal tracking database or the bin and the only way you know if it's being fixed is when a new version of your software appears which magically doesn't break in the same way anymore (and even then you probably don't know if it's really been fixed or if some other change has just hidden it).
Of course the open bug tracking systems only work if people are actually working on the bugs - if you file a bug and it is ignored for a year then clearly you're not going to feel it worthwhile reporting any more.
Your friendly-neihborhood Linux admin can say this stuff all he wants with his other admin buddies, or here on Slashdot. But that doesn't necessarily get heard by even one decision-maker. This will be heard by lots of them, if they are even lightly following online tech-news.
I think that's actually a problem. Most of the decision makers of the world aren't the most technically competent people. If they hear this sort of thing from their friendly admin they can _ask_ what the implications are whereas if they just read it in an article they draw their own conclusions.
From a paranoid and panicy point of view this article can be seen as an announcement that all open source software is insecure and that kind of (incorrect) idea is dangerous in the hands of a decision maker.
On the other hand, from a purely technical point of view it's not saying this at all - it's saying that given a piece of software it would be easier to find the bugs if it were open - if you include the fact that big FOSS projects _generally_ have less bugs than closed projects then this isn't a bad thing for open source.
Re:Fuzzing and Obfuscation
on
Mitnick on OSS
·
· Score: 1
I understand what a buffer overflow is, but I can't for the life of my figure out how to write a buffer overflow that would do anything other than crash.
Your buffer overflow contains the code you want it to execute. However, it must also contain the address of the code you want to execute.
The stack itself contains data and return addresses which tell the system where to resume execution once the function exits. So all you have to do is overwrite the return address with the address pointing at your malicious code. Once the current function exits, the computer jumps to the replaced address and executes your code. The other way of doing things is to trash the stack so that it jumps to some existing code with some parameters of your choosing (i.e. you could jump to the system() function and hand it a parameter like "cat/etc/passwd").
Re:Doublespeak ?
on
Mitnick on OSS
·
· Score: 2, Insightful
So when Mitnick says it is easier to hack OSS software, people say "duh"
He didn't quite say that (infact, he didn't really say a lot). My interpretation of his comment was basically that given 2 pieces of software with a similar number of security holes in it's easier to crack the open stuff (well duh).
Of course, that's ignoring the fact that FOSS software _generally_ seems to be more secure than closed software. You can make up your mind as to why that is, but some thoughts: 1. FOSS software has more people looking at it to find the security holes. 2. If your software is closed you can be much lazier about coding and bugfixing since it's less likely someone (e.g. a peer) will discover your crap code. This means that you will be more inclined to give in the commercial pressures at the expense of security. 3. The person discovering the security hole can (and often does) produce a patch or extensive debugging for FOSS software. This is not possible for closed software. Whilest the patch may not be used in the end it does give the developers a starting point (same goes for debugging - when I've found bugs in FOSS software I have usually done some extensive debugging and can point the developers in the general direction of the bug even if I haven't been able to fix it myself).
Assuming you can get the number of bugs in closed software down to the same level as open software then of course the closed software is going to be more secure, the thing is that the open nature of the software seems to make bugs fewer and that tips the scales.
Note: I am aware that there is crap code in both the open and closed worlds, I'm talking about the _big_ projects here. E.g. Apache vs. IIS, Firefox vs. IE, etc.
Someone just needs to write an open-source SIP/IAX Skype gateway so I can use my SIP phone (now available super-cheap) w/Skype.
The question is: why would you want to? The only think Skype seem to have got right is the marketting, seems much more sane to use SIP since it is the industry standard rather than being stuck with a propriatory protocol with a questionable QoS.
FYI I live in England where healthcare IS free for everyone.
Wrong (to some extent). Generally hospital and doctors are "free" (read - paid for by the tax payer). However, there is no provision for situations when the NHS can't provide the service they are supposed to. I.e. if no NHS dentist will allow you to register (this is the case in much of the UK due to many NHS dentists going private) then you have to pay for private dentistry out of your own pocket. Despite it being _impossible_ to get the NHS service you are entitled to, you don't get a national insurance refund.
They only get away for this because it's a governmental thing - if a commercial organisation was doing this it would be fraud (i.e. you pay for a service and then discover they could never provide it in the first place but they're keeping your money).
What kind of strange definition of explosion does this guy have?
A (low) explosion is basically an over-pressure of the inside of a sealed container to the point that it breaks catestrophically. (High explosives are obviously different). That's not what happened here - the fuel tank ruptured (not caused by an explosion) and the resulting fuel spill just burnt in the air. That's really no different to if your car fuel tank ruptures and the petrol catches fire, it doesn't explode it just burns. Similarly if you set fire to gun powder in an unconfined space it just burns (quickly), it doesn't explode.
The craft then broke apart due to overpressure on the *outside* of the craft (caused by it turning broad-side in a supersonic airstream). If anything that probably constitutes an implosion, certainly not an explosion.
Slashdot Mirror
So... you want to be able to have a single number ring through to 10 alternate numbers at the same time? That makes no sense!
No, actually it makes perfect sense. This is implemented in all traditional PABXes - e.g. someone phones your business and it rings several phones. Whichever is picked up first gets the call. Or another popular implementation of the same idea is hunt groups - i.e. a call comes in and it rings for a short time on one phone, if it isn't answered it rings another phone instead.
What I did say was that google has an imperfect algorithm, and along with punishment for trying to get around that imperfect algorithm, creates a situation where they dictate the rules, and the punishment for not following them.
Alternatively, consider the rules and the punishment to be part of that algorithm. Just because they aren't handled automatically doesn't make them any less relevent as part of the algorithm.
It's this "follow our rules or be punished" attitude that's disturbing.
It's no different to any other advertising medium.
Want to advertise on billboards? The billboard owner and the ASA dictate the sort of content you're allowed to put up. If you piss off the public then it's also likely to come back to bite you in the arse when they complain to either.
In both these cases the rules are good for the consumer - they punish you for putting up misleading or offensive content.
but there is nothing wrong with reasonable use of DRM for protecting intellectual property in a manner consistent with appropriate precedents and law.
The problem here is that many laws are written by the very corporations who are using DRM. At the moment I have the ability to ignore a law (and risk the consequences) if I believe it to be a morally bad law. DRM removes that ability and forces my moral compass to be aligned with the moral corruptness of the lawmakers who were bought out by the content producers.
Infact this all rather reminds me of a police state.
That is possibly the best analogy for DRM I've heard - if I had mod points, you would get them.
I do not understand people that are totally anti-Rights-management.
Because DRM is used in a way that is _too_ restrictive. i.e.:
1. Why shouldn't I be allowed to import a DVD from another region? Maybe it's never going to be available in my region, or maybe it's a lot cheaper if I import it. Yeah, the manufacturers have problems with me buying it from a cheaper region but they don't hesitate to make people redundent because they can employ people to do the same work cheaper elsewhere. If the manufacturers want to exploit the global economy, why do they have the right to prevent their customers from doing the same?
2. Why shouldn't I be allowed to play a DVD using FOSS software? IMHO a mainstream distribution format should not require me to buy specific hardware or software in order to read it - I have legitimately bought the media and a licence to the content, I shouldn't have to pay more money to use it.
3. Even if DRM is only used to prevent you breaking the laws, I worry about this since many people legitimately believe that a lot of laws are bad laws - people should be allowed (to some extent) to be able to use their own moral compass to decide what's right. A good example is the broadcast flag - why should I be prevented from making a video recorder to allow me to time-shift TV shows for my own use? Recording TV shows and then watching them a few hours later doesn't create any adverse effects for anyone so from what I can see the broadcast flag will simply restrict what I can do with the content for no good reason - currently I can ignore such bad laws but if it's actually enforced through technological means I can nolonger make a moral choice for myself.
This is really about trust - why should I trust someone to get the restrictions placed on content right?
The trust issue also applies to things like software signing: being able to lock a machine down so it can only run trusted software on the surface looks attractive - no more malware. But how do I trust the certification authority? e.g. if a machine will only run software that Microsoft certifies as trusted then I have these problems:
1. Why should I trust that MS's definition of "trusted" is the same as mine. For example, Windows Media Player and IE7 both "phone home" - presumably MS thinks that's trustworthy behaviour but I certainly don't.
2. What are the legal implications if MS accidentally signs some malware? If there's no penalty then it seems software signing is useless.
3. Why should I trust that MS won't use software signing to stop 3rd parties producing competing software - what happens when they refuse to sign OpenOffice for example?
Essentially, a certification authority needs to be trusted - what do I base that trust on? In my experience, large companies and governments are both untrustworthy (from the consumer's point of view).
I mean he lists workarounds as 'Firefox'; which just shows how little he understands the security field which he claims to work in (A workaround should be a way to fix or bypass the bug, not a blind pointer at some random other product, even the Linux Security guys know that).
In most cases, yes - a workaround should allow you to continue using your current product. However, in some cases the affected product is considered so fundamentally flawed that alternative products must be considered. Even CERT has (at least once) recommended people replace IE with a different browser in light of a serious security hole.
This is generally the result of lazyness in bugfixing meaning that even though the hole has been known about for a while there is still no patch in the foreseeable future. The answer is to be more proactive - fix bugs as soon as they are found rather than waiting until they are exploited in the wild before starting to engineer a fix. (There are numerous examples of IE security holes that had been known about for many months and a patch was only implemented after exploits started to be widely used in the wild).
most betas are at least close enough to finish that the programmers are looking for the obscure bugs
What surprised me about beta 1 was that they hadn't even finished implementing features that were already on the final product's feature list. Actually, it seemed that they hadn't actually finished deciding what was going on the feature list.
Most people would consider that development stage to be alpha - beta is where you have finished implementing the feature list and you are now after feedback from the customers on bugs, user interface and what extra features they think need to be implemented which weren't on the feature list. I.e. a beta release should fulfill the original specification, albeit still needing some bugfixes.
Uhh. How does it make any difference what company makes a firewall? Code is code, no matter who writes it.
Because Windows is closed source - 3rd parties can't add functionality to existing code, they have to stick to using the hooks provided whereas Microsoft could add functionality right into the stack since they have acces to the source.
Have you any idea how network code actually works?
Yes, actually...
I don't actually have to "bind" to any specific interface in the first place. I just create a socket() -- not bound to any specific interface.
When creating a receiving socket, you can either choose to bind to a specific IP address or you can bind to 0.0.0.0 which essentially binds to all local IP addresses. So the behaviour here is obvious - a bind() call to a specific IP address would be disallowed if it wasn't authorised and a bind() call to 0.0.0.0 would result in the socket only being bound to the authorised IP addresses. Look at the bind(2) man page for more details about binding sockets.
You can send packets without binding first but again, you can make the authorisation check during the connect(2) or sendto(2) call rather than waiting until the packet has gone most of the way through the stack before blocking it.
By the way, as a secondary point, I could imagine a lot of poorly-written applications, assuming that you can just socket(), and get a socket without doing any form of error checking would simply fall over on startup
I would say that this is exactly the sort of software that would contain the most security holes and so preventing it from starting would be a Good Thing. For another reason why making these sorts of bugs obvious is that there are legitimate reasons for the call failing (for example, if you didn't have an IP stack installed)
Finally, putting the firewall in the operating system
I never said that the OS was the wrong place to put it (infact, if anything my idea is more tightly bound to the OS since it's embedded in the IP stack rather than being an external application which hooks at certain points).
and who is going to convince every single application developer to modify their applications so that such a task would be possible?
I suspect providing the framework and having the services that are shipped as standard use it would be a good start. Who convinced the developers to use the "add/remove programs" framework, and yet most (but not all) applications do. I'm not that familiar with windows, but the last time I had to endure Win2k Advanced Server I couldn't actually see a way of telling any of the standard services not to bind to the external NIC - this is something that could be added to the services configuration interface (as well as enable/disable a service you can have tick-boxes telling it what NICs to bind to).
This is available under Linux and Mac OS X with the relatively rough lsof application.
FWIW, "netstat -apn" (under Linux) gives you a nicer output showing what's going on on the network (including unix-domain) side.
A NAT router is not meant to be used as a firewall. It can be used as a line of obscurity, but that's about it.
Errm... who mentioned NAT? The thread was about firewalls: the complaint was made that a firewall needs configuration to allow the right protocols and the "solution" presented was to use UPnP (which is only 1 stage better than just shutting down the damned firewall)
You should really have a final line of defense in a host-level software firewall.
Now I kind of understand how these are built by 3rd parties (since they can't directly modify the IP stack) but I don't understand why Microsoft (who _can_ hack the IP stack) produced a personal firewall. What's the point in letting some malware bind to a NIC and send traffic and then go to the effort of catching that traffic between the IP stack and the wire? It would seem a far better idea to just prevent the unauthorised software from binding to the NIC in the first place, which would prevent it from even being able to generate the unauthorised packets in the first place.
Whilest I agree that firewalls are a useful feature, I question the idea of treating them as a "first line" defense. IMHO the first line of defense is properly configured services - i.e. make sure they bind to the correct NICs. If a service doesn't want to be accessible from the outside world then just don't tell it to bind to the external NIC. The firewall should be treated as a fail-safe incase you screw up and bind a service to the external port (or some malware gets on the machine). It seems that usually firewalls are used as the _only_ line of defense, and in that case there is really no advantage in using a firewall over properly configuring the services since you have no fail-safe to cover you in the event you screw up the firewall config.
A system with all the services bound to the external NIC and a firewall stopping the malicious traffic getting to those services is no more secure than a system with no firewall and the services only bound to the relevent NIC.
I suspect what is needed is simply a unified UI to configure which services are bound where in a similar way to the unified firewall configurators which allow you to open and close any ports from a single UI.
Which Tier 1 routers do you have enable on? Because the ones I've worked on aren't configured for v6
Off the top of my head, Teleglobe carry native IPv6 traffic across their tier-1 network.
At least in North America, v6 and v4 are routed discretely.
IPv4 and IPv6 are discrete protocols - you have to route them discretely. In any case, noone in this thread ever mentioned whether they expected IPv4 and IPv6 to be routed separately or not - you said "A Tier1 provider can't just throw things in their configs and hope everything's OK." which seems redundent - of course they don't just "throw things in their configs and hope", but this doesn't (and hasn't) prevented them from providing native IPv6 tier-1 networks. Just because something's not easy doesn't make it not possible - by your arguement the tier-1 providers would never make *any* changes to their networks for fear of breaking them, but with sufficient testing it's not a problem.
You want to keep spouting off about that which you do not understand? Or are we done here?
I'm not spouting off about things I don't understand - I've worked with both IPv4 and IPv6 networks extensively for years. On the other hand, you haven't yet explained the basis for your crazy arguement claiming that you can't do 6to4 (a system that uses the 6in4 protocol that runs ontop of IPv4) without your ISP implementing a native IPv6 network. You might as well be saying "you can't use GRE without special GRE support from your ISP" which is equally untrue - the ISP only needs to know about the IPv4 level, none of the higher protocols (TCP,UDP, GRE, 6in4, etc). For the record, I have been running 6to4 with no problems for some time with no support on the ISP side.
IPv4 is running out of addresses because early-adopters took huge blocks of space and won't give those addresses up.
Not really - yeah there are a few class A's around but they're not going to make a lot of difference in the grand scheme of things, we still don't have anough addresses. Claiming them back would only buy us a couple more years.
So NAT comes along and provides some relief. But instead of doing it the right way, NATted addresses don't work as a global address.
Uh, how would NAT even allow global addressing? NAT inherrently means you are _destroying_ the original addressing data, making it impossible for your address to be global.
People are just now getting used to the 4-octet addresses and won't be at all comfortable with a switch to longer, harder-to-remember ones.
Most people using the internet never see an IPv4 address anyway - thats what DNS is for. I agree that in certain cases, easy to remember addresses are a Good Thing but to the majority of people I think it's a moot point (and in most of these cases dynamic DNS updates can be used to remove the need to know the IP address)
First of all, reserved blocks of IPv4 address space would be released.
This would involve upgrading IP stacks which are hard-coded to disallow the use of the reserved blocks. If you have to upgrade all the IP stacks you may as well replace them with a better protocol (remember that IPv6 isn't just about more addresses).
Then, NAT2 can be put to good use. NAT2 would allow for scope-resolved addresses.
What you're talking about is essentially a reduced form of source-routing - an idea that is almost universally considered a security problem since crackers can route around a firewall. It also requires a major protocol stack rewrite so bang goes the idea of maintaining compatability - may as well just use IPv6.
The addresses only get long when you build a deep network.
There are significant performance issues with having variable-length addresses, and your idea involves everyone having some idea what the route is to your network - network's aren't nice neat hiararchies (and that's good - hiararchies have poor performance and resilliance).
In short, on the surface your idea looks attractive, but in practice it is unworkable because it would lead to poor performance, resilliance and security.
Just shove a port open request through UPnP.
Except noone sane would enable UPnP on their firewall since it's a major security hole. What's the point in a firewall when malware can turn the damned thing off?
The 'mobile devices' argument is total bullshit.
The only devices that need public IPs are servers.
You are indeed correct - only servers need global scope IP addresses.... Oh wait, in peer to peer networking everyone is both server and client so everyone needs a global scope IP.
The 'mobile devices' arguement is very valid - if you have a mobile SIP phone it needs to be globally addressable (ok, there are work arounds for this problem but they're not nice). How do you think 2 SIP phones talk to eachother when they're both behind NATs? (the answer is they do NAT traversal using protocols like STUN and 3rd party servers which sucks since not only are you relying on a 3rd party but you're relying on the NAT doing what you predict which isn't always the case).
Similarly, when you start up bittorrent, you are starting a server on your machine and people need to be able to connect to it.
Hell, it's a potential security hole to give a non-server a public IP *at all*
No, I'm failing to see that - it's only a security hole if you didn't put a stateful firewall infront of it. The only reason this is seen as a non-issue when doing NAT is because NAT is inherently built ontop of a plain and simple stateful firewall (except usually not a well configured one - with most consumer grade NAT routers you can actually connect to the internal network if the ISP's router is misconfigured).
there is no legitimate reason for wanting to access a mobile phone remotely.
Yes... yes I can see that, there's no reason why a mobile phone should ever want to receive a phone call is there.
Also, ipv6 doesn't get rid of NAT.
Umm, yes it does - IPv6 RFCs _explicitly_ disallow translation of addresses by intermediate routers.
IPv6 is a solution looking for a problem
Really it isn't - it solves a large number of real-world problems which are becoming more important. For example, peer-to-peer applications such as SIP are difficult and unreliable without global addressing (and rely on external servers to help with NAT traversal). With a globally addressed protocol you can do true peer-to-peer without reliance on third parties.
doesnt play with legacy systems
Rubbish - if you can't get a connection over IPv6 you fall back to IPv4. If what you're trying to do isn't possible over IPv4 then frankly you would be no better off if IPv6 didn't exist.
even win2k support is flaky at best
Ah, what a wonderful arguement, "$technology is crap because $lazy_vendor doesn't support it". Here's news for you - IPv6 has been supported in BSD, Linux, MacOS-X and others for _years_. The Win2k IPv6 stack (which incidentally is a _technology preview_) was microsoft's first (half-arsed) attempt at catching up with the other systems which had had support for years. This is very reminicent of IPv4, which MS originally didn't support at all because they considered the Internet to be a "fad" that wasn't worth investing in. Back then you needed to use 3rd-party IPv4 stacks - did that make IPv4 a bad technology that would never be used in the real world?
all those routers and wifi boxes that best buy are selling
The lack of IPv6 support in budget routers is indeed a problem, although one that can be worked around by tunelling over IPv4 (which you have to do anyway if your ISP doesn't support IPv6 natively).
Wifi boxes generally don't matter since they are usually just ethernet bridges - they don't know or care about what protocol you're using. The web interface on an access point is of course accessible only over IPv4 but this isn't a problem, noone's suggesting turning off IPv4 support yet.
most of the ISP's dont want it and dont support it let alone the users figure it out
I don't think that's particularly the case - many larger ISPs already support IPv6 natively. And anywhere you have a global IPv4 address you can tunnel IPv6 without the ISP's participation. The smaller ISPs will catch up once there is more IPv6 being used. This is simply an economics thing - nothing about them not "wanting" it, simply that they can't justify the cost until more people are using it.
Apart from that, NAT is also useful because of an inherent side effect, namely that a basic firewall comes "free" once your router has implemented NAT.
Rubbish - NAT is nothing to do with firewalling. To do NAT you basically take a stateful firewall and glue some extra functionality on top. The NAT bit doesn't add any security over just a plain stateful firewall and creates significant problems for all but the simplest of protocols since there is no (reasonable) way to inform the application of what it's address and ports are being translated to. This leads to peer-to-peer applications such as SIP having to use kludges like STUN, which don't work in all cases.
Far better to have global addressing (i.e. IPv6) and a stateful firewall than the horrible mess that is IPv4+NAT.
Personally, I'd rather have a written guide of some form to refer to when I implement IPv6
The bottom of http://sucs.org/wiki/ipv6 tells you how to configure 6to4 under Fedora Core 4. It's really just a case of setting a couple of options to "yes".
Or their routers aren't routing v6. Or their routers aren't configured for 6to4. Assumedly that would have to be done at the edge, as it would confound fast switching algorithms and push a core router over. Or the core routers between your ISP and your destination's ISP aren't configured for v6. Or your ISP is not getting v6 routes via BGP. Or another half-dozen reasons it won't work.
/48 subnet and the traffic for that subnet is carried between the anycast 6to4 relay router (or other 6to4 gateway) and your 6to4 gateway entirely over IPv4.
WTF are you talking about? You clearly need to go read up on IPv6 because what you just said is complete rubbish. Your ISP does _not_ need to know anything about 6to4. Every IPv4 address is assigned an IPv6
I assume by "that would have to be done at the edge" you mean the edge of the ISP's network, which is incorrect - the encapsulation/de-encapsulation is done at the edge of *your* network. The ISP only sees IPv4 traffic.
They are not blocking traffic when they are not configured to support it.
If the ISP isn't "configured to support" 6to4 then they shouldn't be calling themselves an ISP since they aren't "configured to support" IPv4 in that case.
A Tier1 provider can't just throw things in their configs and hope everything's OK.
Well, firstly, most (all?) tier 1 providers already do _native_ IPv6 and secondly, why exactly do the tier 1 providers need to do any reconfiguration to carry 6to4 traffic?
Do you have any source code examples of this? I understand the concept but I still can't figure out how it works. When I return from a function I am popping information off the stack, so it doesn't matter what I overflow onto the stack while I'm in the function. It gets thrown away when I return.
Note that I'm not a cracker and not really done much theory here so I could be completely wrong, but I *think* the stack on x86 machines is implemented by stacking stuff starting from end rather than from the start (i.e. a buffer overflow will overwrite stuff that was previously pushed into the stack).
Can anyone confirm if this is true, and if it is, is there a good reason since it seems like the dangers of stack overflows could be greatly reduced by stacking from the start?
Well, not just interesting... Most of the people who work on OSS projects do so because they need the project to do something for them.
I think also the open bug-tracking systems using on many FOSS projects help - people are far more likely to report bugs if they get some feedback on them (i.e. you can see it's status in bugzilla, discuss the problem with the developers who are working on it, etc). Compare to most closed development where you send a bug report and it just vanishes - you have no clue if it's gone into some internal tracking database or the bin and the only way you know if it's being fixed is when a new version of your software appears which magically doesn't break in the same way anymore (and even then you probably don't know if it's really been fixed or if some other change has just hidden it).
Of course the open bug tracking systems only work if people are actually working on the bugs - if you file a bug and it is ignored for a year then clearly you're not going to feel it worthwhile reporting any more.
Your friendly-neihborhood Linux admin can say this stuff all he wants with his other admin buddies, or here on Slashdot. But that doesn't necessarily get heard by even one decision-maker. This will be heard by lots of them, if they are even lightly following online tech-news.
I think that's actually a problem. Most of the decision makers of the world aren't the most technically competent people. If they hear this sort of thing from their friendly admin they can _ask_ what the implications are whereas if they just read it in an article they draw their own conclusions.
From a paranoid and panicy point of view this article can be seen as an announcement that all open source software is insecure and that kind of (incorrect) idea is dangerous in the hands of a decision maker.
On the other hand, from a purely technical point of view it's not saying this at all - it's saying that given a piece of software it would be easier to find the bugs if it were open - if you include the fact that big FOSS projects _generally_ have less bugs than closed projects then this isn't a bad thing for open source.
I understand what a buffer overflow is, but I can't for the life of my figure out how to write a buffer overflow that would do anything other than crash.
/etc/passwd").
Your buffer overflow contains the code you want it to execute. However, it must also contain the address of the code you want to execute.
The stack itself contains data and return addresses which tell the system where to resume execution once the function exits. So all you have to do is overwrite the return address with the address pointing at your malicious code. Once the current function exits, the computer jumps to the replaced address and executes your code. The other way of doing things is to trash the stack so that it jumps to some existing code with some parameters of your choosing (i.e. you could jump to the system() function and hand it a parameter like "cat
So when Mitnick says it is easier to hack OSS software, people say "duh"
He didn't quite say that (infact, he didn't really say a lot). My interpretation of his comment was basically that given 2 pieces of software with a similar number of security holes in it's easier to crack the open stuff (well duh).
Of course, that's ignoring the fact that FOSS software _generally_ seems to be more secure than closed software. You can make up your mind as to why that is, but some thoughts:
1. FOSS software has more people looking at it to find the security holes.
2. If your software is closed you can be much lazier about coding and bugfixing since it's less likely someone (e.g. a peer) will discover your crap code. This means that you will be more inclined to give in the commercial pressures at the expense of security.
3. The person discovering the security hole can (and often does) produce a patch or extensive debugging for FOSS software. This is not possible for closed software. Whilest the patch may not be used in the end it does give the developers a starting point (same goes for debugging - when I've found bugs in FOSS software I have usually done some extensive debugging and can point the developers in the general direction of the bug even if I haven't been able to fix it myself).
Assuming you can get the number of bugs in closed software down to the same level as open software then of course the closed software is going to be more secure, the thing is that the open nature of the software seems to make bugs fewer and that tips the scales.
Note: I am aware that there is crap code in both the open and closed worlds, I'm talking about the _big_ projects here. E.g. Apache vs. IIS, Firefox vs. IE, etc.
Someone just needs to write an open-source SIP/IAX Skype gateway so I can use my SIP phone (now available super-cheap) w/Skype.
The question is: why would you want to? The only think Skype seem to have got right is the marketting, seems much more sane to use SIP since it is the industry standard rather than being stuck with a propriatory protocol with a questionable QoS.
FYI I live in England where healthcare IS free for everyone.
Wrong (to some extent). Generally hospital and doctors are "free" (read - paid for by the tax payer). However, there is no provision for situations when the NHS can't provide the service they are supposed to. I.e. if no NHS dentist will allow you to register (this is the case in much of the UK due to many NHS dentists going private) then you have to pay for private dentistry out of your own pocket. Despite it being _impossible_ to get the NHS service you are entitled to, you don't get a national insurance refund.
They only get away for this because it's a governmental thing - if a commercial organisation was doing this it would be fraud (i.e. you pay for a service and then discover they could never provide it in the first place but they're keeping your money).
What kind of strange definition of explosion does this guy have?
A (low) explosion is basically an over-pressure of the inside of a sealed container to the point that it breaks catestrophically. (High explosives are obviously different). That's not what happened here - the fuel tank ruptured (not caused by an explosion) and the resulting fuel spill just burnt in the air. That's really no different to if your car fuel tank ruptures and the petrol catches fire, it doesn't explode it just burns. Similarly if you set fire to gun powder in an unconfined space it just burns (quickly), it doesn't explode.
The craft then broke apart due to overpressure on the *outside* of the craft (caused by it turning broad-side in a supersonic airstream). If anything that probably constitutes an implosion, certainly not an explosion.