I think it is fantastic that people waste gobs of money on virtual advantages. It's one of the best ways to make money today. Long live dummies with too much money! We totally need more dumb people who will pay even more for the 'sheen' of the gold. Extra shine on gold should cost at least 20% extra. Perhaps 'logos' on their WoW items (Nike boots of speed).
In the future, we will see paychecks auto-deposited into WoW type games, and you'll withdraw from your WoW bank account.
I'm sure that the QA aspect of testing the patches takes the most time, because that is where Microsoft has the most to loose.
Imagine if their patch accidentally disabled * * * TENS OF MILLIONS * * * of computers. If that happened, they'd loose so much consumer confidence -- essentially loosing whatever gains (if any) they have made in the last several years (and billions in spending).
(okay, that did happen on a lot of sp2 systems, and MS is not loved for it)
MS has to ensure that the patch works on a staggering and dizzying array of systems and architectures (lots of different mobos, pentiums, AMD's, dual core CPU's, XENON's, via chips), and for dozens upon dozens of applications. That's why you often find that they'll often release a patch on NT or more server based systems before they release it for consumer systems.
Another reason is that, depending on the type of problem, will do a full tracability check, and also cross reference all their code that references the changed module, and evaluate (probably manually) if they put that dependency at risk. A huge, horrible job, suitable only for type-A micro-detail oriented folks. I wouldn't want to do it!
If MS disabled TENS OF MILLIONS of computers, you would see a huge shift away from regular Patch Tuesday activities, towards one of 'install on a test bed' -- extremely tedious and manual that everyone would hate. Millions of people would be put out. Seriously bad Karma.
So, they can:
Release a damaging patch -> like an A-Bomb wiping away consumer confidence
Release a patch late -> some systems might be infected, but often, threats can be mitigated on key systems (firewall rules, policies, use different software), or third party patches appear to fix the problem.
Ignore a problem -> Perhaps try to luer people to exploit it instead of finding new holes?:) Perhaps encouraging the industry to develop technologies like 'IPS' and 'worm crushers'?
I'm sure at least someone is thinking "Heck: our flaws are the manure in which an entire security industry will grow in".
The problem with permissions
on
Insider Threat
·
· Score: 1
One big problem is how we are specifying permissions.
We usually specify who can, or can not, access or modify an object.
So if I want to say 'back up what is important to me', the computer can't do it.
Or, show me 'things which contain financial information', the computer is again lost.
Policies with higher level attributes (either applied to an object, or inferred by content scanning) makes a bit more sense to me, and probably easier to manage.
I would like a flikr like meta-data tag search. Maybe this will be possible with WinFS. It would be more useful if it wasn't entirely free-form, and some template tags and groupings for things like projects and interests were also easily managed.
Anyone know if WinFS is going to be able to take us in this direction?
It's hard to descramble something that is random, or pseudo random. There is no 'key' to break as it were.
Further, the descrambling code would have to be on the system in the first place to begin the descrambling.
Also, the loader could randomize each peice of code each time it was loaded, or possibly even while it was running.
Kind of like Java's 'Hot Spot' run time optimizer, but geared towards making the code running functional, but unknowable, even to a debugger -- at least in practical cases I can think of this afternoon:)
Well, just pick a number. Any number. The point of the number is not to lock into some crazy trustworthy computing (that doesn't trust the user at all - WTF?).
Also, my idea is something that could be implemented on any OS. It's not Windows specific.
Since so many attacks seem to exploit buffer overflows, and there are so many defenses against buffer overflows these days (like the one I just mentioned), it seems to me that a good goal for the end of 2006 is to widely implement some of these capabilities -- perhaps even proactively in some operating systems like OS X, and then we can finally move to a place where "Information Security" can mean more than "Patching against buffer overflow attacks".
Some people say we should be designing things so they have no flaws in them. I say it's impossible, and rather, we should be designing systems that operate gracefully with flaws. Instead of 'fault tolerance', we should be pushing towards a future of 'indestructibility, even with fault injection'.
Why not just auto-scramble the DLL code on the fly for every installation of the Windows OS? That would mean buffer overflows are essentially defeated on a vast majority of cases? One simple thing we could do would be to insert random NOP's in DLL's, making the buffer overflow get the correct offset wrong most of the time and thus fail to work. I'm sure there are dozens of more clever ways to achieve this, in a completely general sort of way.
The reason these attacks spread is that the binary code is essentially a monoculture crop -- all clones of each other. Why not take the SID of a system, or some GUID, and use it to morph all the binary images on a system in a unique way for that system?
Since lots of attacks use NOP's, XOR'd code, and other techniques to avoid being detected as code, why don't we apply the same techniques to our binary objects to obfuscate them from the attacking code?
The only things I've seen more of than Pixar's shorts over the years is original Star Trek episodes. If you, like me, are Pixar'ed out, then detox go and watch some awesome more National Film Board of Canada films:
It's not bad to get 'accurate data' *AT THE TIME OF QUERY*. That's something a lot of people forget about. When you issue your SQL statement, it's the state of data at the time of the query. Things can still go on and change the state of the data, and you can't account for that while your query is running, for you'd never know when to stop your query.
There are also several databases that always know simple things like table counts, or distinct counts of specific fields. One nice one I played with a few years back was the Nitro EDB. Billion record table sets and subsecond response to things like select(distinct somefield) from sometable where _some_daterange_. It maintained hierarchal indexes and some sensible aggrigation.
Here's some thoughts I have on this strange dichotomy between 'schema' and 'indexes':
I see that there is unstructured data, and lots of ways we want to access said data. To access data quickly, we need to index or order it according to some principle. Different needs require different organizational principles. The original structure of the data is logically nice from an aesthetic perspective. E.g. a normalized database with referential integrity makes it easier for us to conceptualize casgading deletions, but it doesn't do much to improve query time. Snowflake and other transformations make the data conceptually closer to analytical use-cases for the data (but harder to load and delete). Then there's the behind the scenes indexes. I find it very difficult to determine exactly *how* an index is being constructed. Is it balanced? How does it optimize itself? I don't like spaghetti-pasta wall approaches like 'drop the indexes and re-create them to see if they're faster'. That's not computer science. It seems to me that an RDBMS should focus more on really great index construction. Keep the data in a form that's very easy to load, change and dump. If that's 3NF, 5NF, something else, great. But the key is just to create a system we can rapidly load, change, dump. After that, let's enter indexland, where we abandon querying our load/change/dump schema, and instead set up some extremely fast, highly space inefficient structures to let me at my data with blinding speed.
There are so many tools for managing schemas, and so few tools by comparison for seamlessly working with indexes. Can anyone tell me which indexes are better/faster under which conditions for MySQL's different engines (InnoDB vs. MyISAM for instance)? MySQL's on-site training couldn't tell me! It's too black box.
I remember using a java Arraylist once as a Fifo queue, and found that if I enqueued a bunch of objects, there was a tremendous non linear slowdown as the implementation of the Arraylist was terrible (it copied itself to new arrays as it grew). And I found out it was O(N) on an element deletion (dequeue), so if I dequeued, I'd have a thousands object reference copies to recon with.
Why don't they even tell us the time complexity of different operations on these index implementations? It seems silly we have to do experiments to reverse engineer these basic things at this point.
Am I right here?
Re:Mainframes Old and Out of Style???
on
Java Is So 90s
·
· Score: 1
I took an SNA course for kicks at IBM and had my head spun around 360 degrees a few times.
I was amazed at the precision and care of the engineering of everything. When a connection failed, it was possible to use diagnostic tools to view exactly how far the state machine got in creating the LU6.2 session. What the tool showed was the specific point where a buffer pool (some VTAM thing?) was insufficient.
I contrast this with IP, where you essentially have ARP and Ping. It's like throwing flares into a void.
Anyway, I've been trying to understand mainframes for years... and have hardly succeeded, but the main thing I can say is that along with mainframes comes a philosophy of discipline, care, proper engineering, ability to design a system that can guarantee response times.
I don't know about you, but I'd like to live in a world where I could engineer a system where I could *guarantee* response times -- not hope for reasonable ones.
Why not create several microkernels, each engineered towards the optimal management of a specific function? I'd say there's room for a master hypervisor, a local real time scheduler, a parallel scheduler, a kernel optimized for guaranteeing bandwidth and resources for drivers, a highly abstract network message passing system, etc...
This, to me, is the only way to have our cake and eat it too, without getting fatter.
Wait! I have it! A solution! Let's just put DRM in the Transistors, Capacitors, Resistors and possibly even the Wires themselves!
So, a transistor will have the normal 3 pins, plus 3 to 6 extra pins for the DRM! A Capacitor, normally two pins, will need 4 extra to ensure it's only operating within its designated range. A normal wire, once DRM enhanced, could have 2 extra conductors to insure its compliance with DRM approved resistance and impedence factors.
Once every transistor in an LCD panel is made safe by DRM, then we will have peace in the middle east.
My experience with Novell is somewhat different than the news item suggests.
I tried, for six months, to license their ZenWorks software distribution system in an OEM capacity and embed it in software I was using. Here's what I discovered:
1) Mean time to return phone call: 12 days 2) Each time someone returned a call, I was forwarded to someone else 3) It took over two months just to get license prices 4) Never did manage to get anything than low level functionaries who enjoyed phone tag
The company needs, in my opinion, some BPR to streamline these sorts of things.
It has a lot of potential, but it is tripping over itself more than it ought to, which looses them revenue and opportunities. I agree RedHat is very $$ oriented, but that ain't a bad thing in running a business these days.
Everyone who has a vested interest in maintaining the 'status quo' will try their darndest to repress, discredit, and sink anything that threatens them, regardless of the benefit to the average citizen.
The inverse is also true: the more a new technology benefits the average citizen, the more opposition it will encounter.
Of course, this only serves to tell the enlightened among us what to check out and buy. If there's lots of people talking trash, there's more often something to it than not.
Slashdot Mirror
I think it is fantastic that people waste gobs of money on virtual advantages. It's one of the best ways to make money today. Long live dummies with too much money! We totally need more dumb people who will pay even more for the 'sheen' of the gold. Extra shine on gold should cost at least 20% extra. Perhaps 'logos' on their WoW items (Nike boots of speed).
In the future, we will see paychecks auto-deposited into WoW type games, and you'll withdraw from your WoW bank account.
Ooop. Ack.
Imagine if their patch accidentally disabled * * * TENS OF MILLIONS * * * of computers. If that happened, they'd loose so much consumer confidence -- essentially loosing whatever gains (if any) they have made in the last several years (and billions in spending).
(okay, that did happen on a lot of sp2 systems, and MS is not loved for it)
MS has to ensure that the patch works on a staggering and dizzying array of systems and architectures (lots of different mobos, pentiums, AMD's, dual core CPU's, XENON's, via chips), and for dozens upon dozens of applications. That's why you often find that they'll often release a patch on NT or more server based systems before they release it for consumer systems.Another reason is that, depending on the type of problem, will do a full tracability check, and also cross reference all their code that references the changed module, and evaluate (probably manually) if they put that dependency at risk. A huge, horrible job, suitable only for type-A micro-detail oriented folks. I wouldn't want to do it!
If MS disabled TENS OF MILLIONS of computers, you would see a huge shift away from regular Patch Tuesday activities, towards one of 'install on a test bed' -- extremely tedious and manual that everyone would hate. Millions of people would be put out. Seriously bad Karma.
So, they can:
I'm sure at least someone is thinking "Heck: our flaws are the manure in which an entire security industry will grow in".
One big problem is how we are specifying permissions.
We usually specify who can, or can not, access or modify an object.
So if I want to say 'back up what is important to me', the computer can't do it.
Or, show me 'things which contain financial information', the computer is again lost.
Policies with higher level attributes (either applied to an object, or inferred by content scanning) makes a bit more sense to me, and probably easier to manage.
I would like a flikr like meta-data tag search. Maybe this will be possible with WinFS. It would be more useful if it wasn't entirely free-form, and some template tags and groupings for things like projects and interests were also easily managed.
Anyone know if WinFS is going to be able to take us in this direction?
Fair enough.
What if the number was more random? Wide spectrum radio receiver in a chip, spitting out entropy?
Paul Sop
It's hard to descramble something that is random, or pseudo random. There is no 'key' to break as it were.
:)
Further, the descrambling code would have to be on the system in the first place to begin the descrambling.
Also, the loader could randomize each peice of code each time it was loaded, or possibly even while it was running.
Kind of like Java's 'Hot Spot' run time optimizer, but geared towards making the code running functional, but unknowable, even to a debugger -- at least in practical cases I can think of this afternoon
Paul Sop
Well, just pick a number. Any number. The point of the number is not to lock into some crazy trustworthy computing (that doesn't trust the user at all - WTF?).
Also, my idea is something that could be implemented on any OS. It's not Windows specific.
Since so many attacks seem to exploit buffer overflows, and there are so many defenses against buffer overflows these days (like the one I just mentioned), it seems to me that a good goal for the end of 2006 is to widely implement some of these capabilities -- perhaps even proactively in some operating systems like OS X, and then we can finally move to a place where "Information Security" can mean more than "Patching against buffer overflow attacks".
Some people say we should be designing things so they have no flaws in them. I say it's impossible, and rather, we should be designing systems that operate gracefully with flaws. Instead of 'fault tolerance', we should be pushing towards a future of 'indestructibility, even with fault injection'.
Paul Sop
Why not just auto-scramble the DLL code on the fly for every installation of the Windows OS?
That would mean buffer overflows are essentially defeated on a vast majority of cases? One simple thing we could do would be to insert random NOP's in DLL's, making the buffer overflow get the correct offset wrong most of the time and thus fail to work. I'm sure there are dozens of more clever ways to achieve this, in a completely general sort of way.
The reason these attacks spread is that the binary code is essentially a monoculture crop -- all clones of each other. Why not take the SID of a system, or some GUID, and use it to morph all the binary images on a system in a unique way for that system?
Since lots of attacks use NOP's, XOR'd code, and other techniques to avoid being detected as code, why don't we apply the same techniques to our binary objects to obfuscate them from the attacking code?
Paul Sop
The only things I've seen more of than Pixar's shorts over the years is original Star Trek episodes. If you, like me, are Pixar'ed out, then detox go and watch some awesome more National Film Board of Canada films:
http://www.nfb.ca/trouverunfilm/?v=h&lg=en
WAY more material here. (anyone remember the Jumblies stamp movie! oooh that was great!)
It's not bad to get 'accurate data' *AT THE TIME OF QUERY*. That's something a lot of people forget about. When you issue your SQL statement, it's the state of data at the time of the query. Things can still go on and change the state of the data, and you can't account for that while your query is running, for you'd never know when to stop your query.
There are also several databases that always know simple things like table counts, or distinct counts of specific fields. One nice one I played with a few years back was the Nitro EDB. Billion record table sets and subsecond response to things like select(distinct somefield) from sometable where _some_daterange_. It maintained hierarchal indexes and some sensible aggrigation.
Here's some thoughts I have on this strange dichotomy between 'schema' and 'indexes':
I see that there is unstructured data, and lots of ways we want to access said data. To access data quickly, we need to index or order it according to some principle. Different needs require different organizational principles. The original structure of the data is logically nice from an aesthetic perspective. E.g. a normalized database with referential integrity makes it easier for us to conceptualize casgading deletions, but it doesn't do much to improve query time. Snowflake and other transformations make the data conceptually closer to analytical use-cases for the data (but harder to load and delete). Then there's the behind the scenes indexes. I find it very difficult to determine exactly *how* an index is being constructed. Is it balanced? How does it optimize itself? I don't like spaghetti-pasta wall approaches like 'drop the indexes and re-create them to see if they're faster'. That's not computer science. It seems to me that an RDBMS should focus more on really great index construction. Keep the data in a form that's very easy to load, change and dump. If that's 3NF, 5NF, something else, great. But the key is just to create a system we can rapidly load, change, dump. After that, let's enter indexland, where we abandon querying our load/change/dump schema, and instead set up some extremely fast, highly space inefficient structures to let me at my data with blinding speed.
There are so many tools for managing schemas, and so few tools by comparison for seamlessly working with indexes. Can anyone tell me which indexes are better/faster under which conditions for MySQL's different engines (InnoDB vs. MyISAM for instance)? MySQL's on-site training couldn't tell me! It's too black box.
I remember using a java Arraylist once as a Fifo queue, and found that if I enqueued a bunch of objects, there was a tremendous non linear slowdown as the implementation of the Arraylist was terrible (it copied itself to new arrays as it grew). And I found out it was O(N) on an element deletion (dequeue), so if I dequeued, I'd have a thousands object reference copies to recon with.
Why don't they even tell us the time complexity of different operations on these index implementations? It seems silly we have to do experiments to reverse engineer these basic things at this point.
Am I right here?
I took an SNA course for kicks at IBM and had my head spun around 360 degrees a few times.
I was amazed at the precision and care of the engineering of everything. When a connection failed, it was possible to use diagnostic tools to view exactly how far the state machine got in creating the LU6.2 session. What the tool showed was the specific point where a buffer pool (some VTAM thing?) was insufficient.
I contrast this with IP, where you essentially have ARP and Ping. It's like throwing flares into a void.
Anyway, I've been trying to understand mainframes for years... and have hardly succeeded, but the main thing I can say is that along with mainframes comes a philosophy of discipline, care, proper engineering, ability to design a system that can guarantee response times.
I don't know about you, but I'd like to live in a world where I could engineer a system where I could *guarantee* response times -- not hope for reasonable ones.
Lots of respect for those IBM folks.
Why not create several microkernels, each engineered towards the optimal management of a specific function? I'd say there's room for a master hypervisor, a local real time scheduler, a parallel scheduler, a kernel optimized for guaranteeing bandwidth and resources for drivers, a highly abstract network message passing system, etc...
This, to me, is the only way to have our cake and eat it too, without getting fatter.
Wait! I have it! A solution! Let's just put DRM in the Transistors, Capacitors, Resistors and possibly even the Wires themselves!
So, a transistor will have the normal 3 pins, plus 3 to 6 extra pins for the DRM!
A Capacitor, normally two pins, will need 4 extra to ensure it's only operating within its designated range.
A normal wire, once DRM enhanced, could have 2 extra conductors to insure its compliance with DRM approved resistance and impedence factors.
Once every transistor in an LCD panel is made safe by DRM, then we will have peace in the middle east.
My experience with Novell is somewhat different than the news item suggests.
I tried, for six months, to license their ZenWorks software distribution system in an OEM capacity and embed it in software I was using. Here's what I discovered:
1) Mean time to return phone call: 12 days
2) Each time someone returned a call, I was forwarded to someone else
3) It took over two months just to get license prices
4) Never did manage to get anything than low level functionaries who enjoyed phone tag
The company needs, in my opinion, some BPR to streamline these sorts of things.
It has a lot of potential, but it is tripping over itself more than it ought to, which looses them revenue and opportunities. I agree RedHat is very $$ oriented, but that ain't a bad thing in running a business these days.
Everyone who has a vested interest in maintaining the 'status quo' will try their darndest to repress, discredit, and sink anything that threatens them, regardless of the benefit to the average citizen.
The inverse is also true: the more a new technology benefits the average citizen, the more opposition it will encounter.
Of course, this only serves to tell the enlightened among us what to check out and buy. If there's lots of people talking trash, there's more often something to it than not.
People hate change.
I am too. Email me if u ever need a copy of it. lots of fun stuff in it. doom wad's, lots of great papers, peoples vacation photos.