(This is what i read in some article some time ago, so it may be false/false remembrance)
The destruction of the original is part of the copying process, so its more a mv than a cp:
To copy a quantum state of a particle, you have to read it. Measuring it's quantum state alters it into a (random?) new quantum state. So scanning a complex body destroys all it's atom's states, thus tranforming the body into a pile of particles. You cannot keep the original intact.
Mozilla Foundation stopped supporting Thunderbird development apparently because the organization got no money for it, and Google wants you to use web mail, so that you will see the ads.
... but a 25x increase in the speed of bruteforcing passwords will certaintly speed up the process by which passwords are obseleted.
25 < 26, so one more character is enough. Even if you calculate that a standard user password only has 2bit of entropy per character, three more will do it.
I agree password-only authentication should become obsolete. But factor 25x is not really much in cracking./g.
Eerrr... tautologically true, yes: if there is no paravirtualized version of the OS you want to use, paravirtualization is not an option. But there are many scenarios where you are only interested in running lots of paravirtualizable unixish OSes, eg server farming.
Paravirtualization (running hypervisor-aware guest kernels, eg patched linux on xen) is faster than both, binary translation and "full" virtualization. And you don't need CPUs with VT extension.
g
The real problem with trusted computing
on
The FSF, GPLv3 and DRM
·
· Score: 2, Insightful
is not keeping secret keys secret. It's the missing possibility to edit the list of pubkeys which the trusted computing (TC) mechanism acccepts!
bad thing:
Tivo sign their kernels using their secret key.
Tivo's bootloader refuses to boot any kernel not signed by tivo
good thing (prevents trojan LKMs):
RH sign their LKMs using their secret key.
A RH kernel binary refuses to load any LKM not signed by RH.
As far as i understood the discussion, GPLv3 thinks that (1.1) is the problem, so it demands publishing the secret key. But that's wrong and renders (2) useless.
Instead, the problem is (1.2): i cannot append my own pubkey to the bootloaders list of approved binary signing keys, although i "own" that bootloader. Instead with (2.2), i can build and run my own kernel image embedding a different list of acceptable LKM signing keys.
So if one wants to prevent such a mess like tivo, (s)he should use a licence that demands that the software is not run on devices with a write protected TC pubkey list. I'd perfectly happy with TC if i could enter the fingerprints of valid TC-pubkeys into the BIOS.
We have always had an explicit allow list for isakmp packets only for the known peers
It's allways a good idea to restrict access to a service to legitimate peers on layer 3. Unfortunatly, this does not work if your peers use unpredictable IPs (VPN-roadwarriors).
It does look like an attack vector which should bother lots of admins.
Troubleshooting a network is a matter of experience, not of some particular tools. But these things help:
* Put you box on the monitor/mirror/analysing port of the switch an read the traffic with tcpdump/tethereal/ethereal (If you just want to check the broadcasts, it does not have to be a monitoring port). Edit the packet filter expression until you do not see the legal/uninteresting traffic anymore but only the suspects. (They are students? Have fun to filter all the p2p traffic;-) Let ethereal make statistics over the traffic.
* Watch out for ICMP errors, especially ICMP-redirects. Watch out for TCP-resets. Watch out for fragments. Watch out for malicious Spanning-Tree packets. Watch for SMTP to many IPs (spamming trojans), IRC (zombies), weird packets eg. fragmented UDP (zombies attacking a target)
* Check the MAC adresses in the etherframe-header ('tcpdump -e'): are they constant? If there are packets IP_AIP_B, are the accordings MACs really MAC_AMAC_B or MAC_A-->MAC_B and MAC_B-->MAC_C instead?
* Install an arpwatcher. Stealing the default-gateway's MAC is an effective DoS attack on a network.
* Put 2 NICs into a fast linux box, bridge ('brctl') them together, put this linuxbridge in front of the default-gateway. Dump again. Install a snort on it and let it see the traffic - what does the snort log say?
* Do the switches have the feature to log to a remote syslog deamon? Do so and read those logs! Check all the snmp-variables on the switches, especially the "errors". Read the logs of the default-gateway.
* Watch the amount of traffic (snmpget the port-counters of the switches and make mrtg-graphs of the results). Maybe the problem only strikes if some switch ports are under high load?
* Scan the network with nessus. Maybe you'll find some bindshells.
Just returning from a one hour shopping expedition (in a german city) with a laptop in my backpack: 98 APs = 9 WPA + 29 WPA/WEP + 42 WEP + 18 unencrypted. Remember most WEP installations can be broken into (google for aircrack) with enough 802.11b frames collected.
So it's about 20% unprotected, 40% badly protected and 30% badly protected if WEP mode is used by clients.
These are blind exploits, meaning you do NOT have to be a man-in-the-middle.
If the error receiving system is checking the header of the error generating tcp or udp packet (at least 8 byte have to be contained in the icmp error), the attacker has to guess the source port and - in case if tcp - the tcp sequence number to work blindly.
Sequence number checking is not enough. Therefore Linux has not fully fixed these issues yet. Only OpenBSD has fixed them all, and it must be considered the reference implementation for these fixes. TCP window sizes are fairly large these days. You can EASILY exploit this in a few seconds simply by brute forcing into the window.
Again: you have to guess the source port, too. There are very few tcp protocols with predictable source ports nowadays. So it's not 2^32/windowsize but probably (2^16-1024)*2^32/windowsize. Have fun brute forcing that.
This is much worse than the TCP reset attacks we read about. Why? Because using these ICMP exploits, you can stall a connection without the application layer ever receiving notification that something is amiss.
True: such an attack would feel more like a network problem than like an attack.
Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels.
And they secure them by no longer using predictable source ports (many BGP implementations used dest port = source port (179) before).
This issue has to be considered, but as D. Adams said: Don't panic!
I wonder if someone has done RAID mixing local harddrives and network block devices like GNBD or iSCSI? Should be ok on gigabit speed, right?
I know DRDB, but that's more for HA pairs and cannot sync drives in background while mounted.
/graf0z.
Re:Solaris Zones vs User Mode Linux
on
Solaris 10 Released
·
· Score: 2, Informative
Currently I'm using a UML provider for my website / email / etc. I will be very interesting to see if Solaris 10 Zones perform better.
I am currently using UML for running multiple servers on one host, and a collegue runs multiple linuces with XEN (he runs it on his desktop, too!), and he says it performs near to native. He demonstrated it to me, very impressive. Easier to administrate than UML. I'll switch to xen. And ISPs will, too.
I'll check opensolaris when it's ported to the xen-arch like netbsd and -soon- freebsd.
The first one is about shortcuts in spacetime (You would end up in a certain location much faster than if you travelled there the 'normal way,' kind of like a secret passage. Happily for relativity, you would STILL not actually be travelling faster than the speed of light in local space, so Einstein's 'speed limit' still holds. The second article is humbug, for example is mixes up mass and gravitational force upon a mass ("weight").
The pristine IPsec protocol family lacked two key features: the ability to pass NAT and TLS/SSL-alike hybrid authentication. If these features would have been built into IPsec and its implementations ten years ago, network layer encryption would be far more used and crappy stuff like PPTP would never have raised its ugly head. (i know this does not hold the abstract's requirements for "shortcomings", but i think the internet would look different today without it)
The NAT problem got resolved by UDP encapsulation ("NAT-T" = NAT traversal, after years of being a draft finally published 5 days ago as RFC) got implemented by most vpn software during the past two years (= too late).
Hybrid auth means: peer A ("the server") authenticates itself to peer B ("the client") through asymmetric methods (like an RSA keypair and a X.509v3 cert). Peer B chooses a random symmetric session key and encrypts it for A, this sets up an encrypted tunnel. Inside this tunnel, B authenticates itself to A using simpler techniques like challenge-response or even clear passwords. Allmost all personalized TLS/SSL protected services (https, pop3s, imaps,...) work this way: Servers has a cert, client has a password. Easy to admin, easy to deploy, easy to rollout.
But with IPsec/IKE/ISAKMP you have to choose between shared secrets (bah!) or rolling out keypairs to all peers. And like all other protocols requiring all peers to be part of a PKI (PGP, S/MIME, SSL+certs on both sides) this slowed down propagation strongly.
It couldn't be the Internet, since that is obviously older than 25 years.
According to sources like Wikipedia so are cell phones (#2), personal computers (#3), Memory storage discs (#8) or ATMs (#14) (if ATM=cash machine). CNN probably means "inventions which became popular during the last 25 years, even if they where invented 70 years ago". So it cound very well be "the internet" (developed late 60s), not only "the www" (http + html, early 80s).
i) Abel's proof contains a flaw that generations of extremely talented mathematicians have failed to spot in their years and years of teaching it.
ii) Student mistaken; popular media talking out of arse.
iii) Abel's theorem holds ("you cannot solve all polynomial equations by radicals"); student solves all polynomial equations not using radicals but using differential equations and power series; popular media like/. do not understand that this method is known for more than hundred years and that there is no inconsistence.
false positives: if this problem does not get solved, IDS won't work on larger sites. One solution could - maybe - be the interaction of an network IDS with a vulnerability scanner (eg
packetalarm which combines snort with nessus or the above mentioned quidscor) Roesch indicated. Smart attacks try to hide the actual exploit inside the intentional white noise of false positives.
false positives.
false positives.
encrypted traffic: if an ipsec roadwarrior attacks a service or an attacker targets the https-port of a webserver (not using detectable openssl-overflows:-), the IDS sensor has to sit between encryption endpoint and the target. That means that You may have to terminate https with stunnel at your IDS-sensor one hop in front of your apache instead of using mod_ssl... And how do You detect malicious content in gpg-encrypted mails?
"protocol tunneling" or "firewall piercing": how do You detect an trojan inside a corrupted internal workstation calling home through harmlessly looking traffic like http (or even https)? It could craft the http-requests to be indistinguishable from real user traffic (using same proxy and proxy-credentials as the user if nesseccary).
everyday a new way of obfuscating exploits. Modern IDS know tcp-segment-reassembly, ip-fragment-reassembly, hundred ways of quoting and encoding (like unicode), but it's hard to catch up hackers creativity.
polymorphic attacks: we've already seen polymorphic shellcode. There will be polymorphic attacks as well. Your IDS engine will have to be much smarter than matching regex to detect those!
hand crafted variations of known exploits: there are open source exploits which can be modified such that the according snort rules does not strike any more.
there are myriads of exploitable cgi/php/.. scripts: once coded by a poor student or - worse - a webdesigner, never updated, not publicly known. The chance is not too bad for an experienced hacker to construct a never-seen-before exploit against some ancient webshop. If he avoids the well known evidences (like typing "id" into an unencrypted bindshell) the IDS won't scream.
I fear that when attackers learn to make heavy use of triggering massive false positives, crypto & steanography, protocol-tunneling and start to build exploit-engines producing polymorphic code the days of pattern matching IDS are count. Maybe anomaly-detection (using statistics or neural networks) will help.
we lost power for 5 days last December and again for 4 days last January
Consider switching your energy provider or moving to a place where
energy providers have heard of "redundancy". (I recommend central europe. All outages i remember sum up to less than 1 hour - over the last 30 years!)
Or you may earn a lot of bucks producing and/or selling candles;-)
The settlement is based on this preliminary injunction from may 30 2003 containing - besides juristic framework - just one sentence:
Der Antragsgegnerin wird [...] verboten, im geschaeftlichen Verkehr die Behauptung zu verbreiten, dass LINUX-Betriebssysteme unrechtmaessig erworbenes Eigentum von SCO UNIX beinhalten und/oder dass Endanwender, die LINUX einsetzen, fuer die damit verbundenen Schutzrechtsverletzungen der SCO Intellectual Properties haftbar gemacht werden koennen.
I try to translate, but beware my english (maybe someone can do a better job on this):
[SCO Group GmbH] must not spread the assertion that linux operating systems contain unlawfully obtained property of SCO UNIX and/or that end users could get hold responsible for implicated intellectual property infringement implicated by using linux.
Summary of changes from v2.4.24-pre3 to v2.4.25-pre4
[...] Andrea Arcangeli: malicious users of mremap() syscall can gain priviledges
Date of patch-2.4.25-pre4-pre5 (did not find pre3-pre4) ist Jan-15! Why did it take so long to get the crowd informed? Same thing happened with the other do_mremap() bug.
Slashdot Mirror
Maybe the dock will have it (like the ones for the T-series). And by the way: what about eSata? /g.
ps: never had a notebook which wasn't a thinkpad
The destruction of the original is part of the copying process, so its more a mv than a cp:
To copy a quantum state of a particle, you have to read it. Measuring it's quantum state alters it into a (random?) new quantum state. So scanning a complex body destroys all it's atom's states, thus tranforming the body into a pile of particles. You cannot keep the original intact.
Can anybody confirm/refute that?
So let's fork it! Oh, already done
Isn't FOSS great?
Note to myself: This is /. so i shall not post obvious facts. Other will do it for me, and they are always faster.
25 < 26, so one more character is enough. Even if you calculate that a standard user password only has 2bit of entropy per character, three more will do it.
I agree password-only authentication should become obsolete. But factor 25x is not really much in cracking. /g.
Your windows desktop is not the whole point.
g
g
- bad thing:
- Tivo sign their kernels using their secret key.
- Tivo's bootloader refuses to boot any kernel not signed by tivo
- good thing (prevents trojan LKMs):
- RH sign their LKMs using their secret key.
- A RH kernel binary refuses to load any LKM not signed by RH.
As far as i understood the discussion, GPLv3 thinks that (1.1) is the problem, so it demands publishing the secret key. But that's wrong and renders (2) useless.Instead, the problem is (1.2): i cannot append my own pubkey to the bootloaders list of approved binary signing keys, although i "own" that bootloader. Instead with (2.2), i can build and run my own kernel image embedding a different list of acceptable LKM signing keys.
So if one wants to prevent such a mess like tivo, (s)he should use a licence that demands that the software is not run on devices with a write protected TC pubkey list. I'd perfectly happy with TC if i could enter the fingerprints of valid TC-pubkeys into the BIOS.
Just my 2ct, m.
It's allways a good idea to restrict access to a service to legitimate peers on layer 3. Unfortunatly, this does not work if your peers use unpredictable IPs (VPN-roadwarriors).
It does look like an attack vector which should bother lots of admins.
graf0z.
Troubleshooting a network is a matter of experience, not of some particular tools. But these things help:
;-) Let ethereal make statistics over the traffic.
...
* Put you box on the monitor/mirror/analysing port of the switch an read the traffic with tcpdump/tethereal/ethereal (If you just want to check the broadcasts, it does not have to be a monitoring port). Edit the packet filter expression until you do not see the legal/uninteresting traffic anymore but only the suspects. (They are students? Have fun to filter all the p2p traffic
* Watch out for ICMP errors, especially ICMP-redirects. Watch out for TCP-resets. Watch out for fragments. Watch out for malicious Spanning-Tree packets. Watch for SMTP to many IPs (spamming trojans), IRC (zombies), weird packets eg. fragmented UDP (zombies attacking a target)
* Check the MAC adresses in the etherframe-header ('tcpdump -e'): are they constant? If there are packets IP_AIP_B, are the accordings MACs really MAC_AMAC_B or MAC_A-->MAC_B and MAC_B-->MAC_C instead?
* Install an arpwatcher. Stealing the default-gateway's MAC is an effective DoS attack on a network.
* Put 2 NICs into a fast linux box, bridge ('brctl') them together, put this linuxbridge in front of the default-gateway. Dump again. Install a snort on it and let it see the traffic - what does the snort log say?
* Do the switches have the feature to log to a remote syslog deamon? Do so and read those logs! Check all the snmp-variables on the switches, especially the "errors". Read the logs of the default-gateway.
* Watch the amount of traffic (snmpget the port-counters of the switches and make mrtg-graphs of the results). Maybe the problem only strikes if some switch ports are under high load?
* Scan the network with nessus. Maybe you'll find some bindshells.
*
Hope this helps.
g.
So it's about 20% unprotected, 40% badly protected and 30% badly protected if WEP mode is used by clients.
- These are blind exploits, meaning you do NOT have to be a man-in-the-middle.
- Sequence number checking is not enough. Therefore Linux has not fully fixed these issues yet. Only OpenBSD has fixed them all, and it must be considered the reference implementation for these fixes. TCP window sizes are fairly large these days. You can EASILY exploit this in a few seconds simply by brute forcing into the window.
- This is much worse than the TCP reset attacks we read about. Why? Because using these ICMP exploits, you can stall a connection without the application layer ever receiving notification that something is amiss.
- Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels.
This issue has to be considered, but as D. Adams said: Don't panic!If the error receiving system is checking the header of the error generating tcp or udp packet (at least 8 byte have to be contained in the icmp error), the attacker has to guess the source port and - in case if tcp - the tcp sequence number to work blindly.
Again: you have to guess the source port, too. There are very few tcp protocols with predictable source ports nowadays. So it's not 2^32/windowsize but probably (2^16-1024)*2^32/windowsize. Have fun brute forcing that.
True: such an attack would feel more like a network problem than like an attack.
And they secure them by no longer using predictable source ports (many BGP implementations used dest port = source port (179) before).
Btw: Not 11^281+1 itself (which has obviously >281 decimal digits) was the previous world record, but a 176-digit factor of 11^281+1 called "c176":
/graf0z.I know DRDB, but that's more for HA pairs and cannot sync drives in background while mounted.
I am currently using UML for running multiple servers on one host, and a collegue runs multiple linuces with XEN (he runs it on his desktop, too!), and he says it performs near to native. He demonstrated it to me, very impressive. Easier to administrate than UML. I'll switch to xen. And ISPs will, too.
I'll check opensolaris when it's ported to the xen-arch like netbsd and -soon- freebsd.
The first one is about shortcuts in spacetime (You would end up in a certain location much faster than if you travelled there the 'normal way,' kind of like a secret passage. Happily for relativity, you would STILL not actually be travelling faster than the speed of light in local space, so Einstein's 'speed limit' still holds. The second article is humbug, for example is mixes up mass and gravitational force upon a mass ("weight").
The NAT problem got resolved by UDP encapsulation ("NAT-T" = NAT traversal, after years of being a draft finally published 5 days ago as RFC) got implemented by most vpn software during the past two years (= too late).
Hybrid auth means: peer A ("the server") authenticates itself to peer B ("the client") through asymmetric methods (like an RSA keypair and a X.509v3 cert). Peer B chooses a random symmetric session key and encrypts it for A, this sets up an encrypted tunnel. Inside this tunnel, B authenticates itself to A using simpler techniques like challenge-response or even clear passwords. Allmost all personalized TLS/SSL protected services (https, pop3s, imaps, ...) work this way: Servers has a cert, client has a password. Easy to admin, easy to deploy, easy to rollout.
But with IPsec/IKE/ISAKMP you have to choose between shared secrets (bah!) or rolling out keypairs to all peers. And like all other protocols requiring all peers to be part of a PKI (PGP, S/MIME, SSL+certs on both sides) this slowed down propagation strongly.
There is an IETF draft "A Hybrid Authentication Mode for IKE" which is adopted my more and more implementations right now (= far too late). Cisco is now pushing it because of the failure of their own "group password scheme" (of course they name it differently: "Mutual Group Authentication").
Man, why did they wait so long?
According to sources like Wikipedia so are cell phones (#2), personal computers (#3), Memory storage discs (#8) or ATMs (#14) (if ATM=cash machine). CNN probably means "inventions which became popular during the last 25 years, even if they where invented 70 years ago". So it cound very well be "the internet" (developed late 60s), not only "the www" (http + html, early 80s).
ii) Student mistaken; popular media talking out of arse.
iii) Abel's theorem holds ("you cannot solve all polynomial equations by radicals"); student solves all polynomial equations not using radicals but using differential equations and power series; popular media like /. do not understand that this method is known for more than hundred years and that there is no inconsistence.
ps: a link provided by the author himself: solving the quintic
DC Phone Home (ppt, rtsp only).
Great. /graf0z.
I fear that when attackers learn to make heavy use of triggering massive false positives, crypto & steanography, protocol-tunneling and start to build exploit-engines producing polymorphic code the days of pattern matching IDS are count. Maybe anomaly-detection (using statistics or neural networks) will help.
Just my 2ct. /graf0z
Consider switching your energy provider or moving to a place where energy providers have heard of "redundancy". (I recommend central europe. All outages i remember sum up to less than 1 hour - over the last 30 years!)
Or you may earn a lot of bucks producing and/or selling candles ;-)
Der Antragsgegnerin wird [...] verboten, im geschaeftlichen Verkehr die Behauptung zu verbreiten, dass LINUX-Betriebssysteme unrechtmaessig erworbenes Eigentum von SCO UNIX beinhalten und/oder dass Endanwender, die LINUX einsetzen, fuer die damit verbundenen Schutzrechtsverletzungen der SCO Intellectual Properties haftbar gemacht werden koennen.
I try to translate, but beware my english (maybe someone can do a better job on this):
[SCO Group GmbH] must not spread the assertion that linux operating systems contain unlawfully obtained property of SCO UNIX and/or that end users could get hold responsible for implicated intellectual property infringement implicated by using linux.
Thanks to LEO
From the ChangeLog of kernel-2.4.25:
Date of patch-2.4.25-pre4-pre5 (did not find pre3-pre4) ist Jan-15! Why did it take so long to get the crowd informed? Same thing happened with the other do_mremap() bug.Hacker's guide: