Why can't we have a computer like Amiga?

[kolla]

When I hacked remote Amigas (it happened), it was client software I exploited (AmIRC for example, all those scripts people use without thinking of the consequences). If an Amiga had TCP: mounted, executing remote scripts was a breeze. One funny game was to have remote amiga export ram: with netfs, so I could mount it from my amiga, assign my env: to remote env: and play around with system prefs and see confused owners rambling on IRC as their pallette changed or whatever. Back in the days people didn't have NAT to hide behind, today it requires a wee bit more effort. Astonishingly many use default admin passwords on their routers, or the same password for admin user as for their wifi.

Bottom line is, if you let anything from remote source run on your Amiga, your entire system may be owned within seconds.

Maynaf, memory protection helps a lot in terms of limiting what an exploiter can perform on a system, if you think otherwise, then please explain.

[Mrs Beanbag]

@kolla: THANK YOU
also do you know what is the "finger exploit" mentioned here? http://eab.abime.net/showthread.php?t=18952

@meynaf: yes i do know how much code you can fit in 20kb, i have written Amiga code you know. I have also written C++ code for commercial projects and as much as i'm astonished at how big the executables come out from GCC, but that's got no bearing on the complexity from a programming point of view. But no matter how good a compiler you had, or if you were writing it all in ASM, you wouldn't fit Photoshop in 20kb, even Deluxe Paint doesn't fit in 20kb. Someone from ZX81 community probably calls that bloatware, too!

[meynaf]

Originally Posted by kolla

When I hacked remote Amigas (it happened), it was client software I exploited (AmIRC for example, all those scripts people use without thinking of the consequences). If an Amiga had TCP: mounted, executing remote scripts was a breeze. One funny game was to have remote amiga export ram: with netfs, so I could mount it from my amiga, assign my env: to remote env: and play around with system prefs and see confused owners rambling on IRC as their pallette changed or whatever. Back in the days people didn't have NAT to hide behind, today it requires a wee bit more effort. Astonishingly many use default admin passwords on their routers, or the same password for admin user as for their wifi.

Well, let's admit i connect some Amiga and you hack it. What would you do exactly ? Even if I don't close ports in MiamiDx, you will NOT pass.
And should you pass nevertheless, you'd be ejected (by me) as quickly as you entered ! If you can enter - which i seriously doubt - you can not do anything unnoticed.

Originally Posted by kolla

Bottom line is, if you let anything from remote source run on your Amiga, your entire system may be owned within seconds.

... IF you let anything run.
But, boy, if you let anything from a remote source run, your entire system may be owned within seconds... regardless of the machine you use.

... and for me it can also be un-owned within seconds. I disconnect, or even perform ctrl-A-A. Then you lose all control.

Originally Posted by kolla

Maynaf, memory protection helps a lot in terms of limiting what an exploiter can perform on a system, if you think otherwise, then please explain.

Nah, this is reversing the charge of the proof. I don't see any attack done without memory protection, that can not also be done with it.
Remember that all the zombie peecees sending spam all have memory protection. A good firewall does a lot more than memory protection ever did.


Anyway as I said earlier, it's pointless to have "security" when you have no risk of being attacked ! We're in a market niche, remember.

My point of view on memory protection is that it should be an OPTION. What's wrong in that ???

[meynaf]

Originally Posted by Mrs Beanbag

@kolla: THANK YOU

Were you in difficulty so that you needed some help ?

Originally Posted by Mrs Beanbag

@meynaf: yes i do know how much code you can fit in 20kb, i have written Amiga code you know. I have also written C++ code for commercial projects and as much as i'm astonished at how big the executables come out from GCC, but that's got no bearing on the complexity from a programming point of view. But no matter how good a compiler you had, or if you were writing it all in ASM, you wouldn't fit Photoshop in 20kb, even Deluxe Paint doesn't fit in 20kb. Someone from ZX81 community probably calls that bloatware, too!

Of course there is some complexity, but you have to admit that current sizes are a lot too high for what programs do.

The compiler is responsible only of a small part in fact ; it turns 20kb programs into 80kb programs maybe, but it won't turn 20kb into several Mb.
Bloatwares are so by bad programming design, it's not the fault of the compiler. Look at the sources that can be found online. Often i can rewrite them in asm with a lot less lines !
How many lines is it to show a PNG for example ?

[Mrs Beanbag]

Originally Posted by meynaf

Anyway as I said earlier, it's pointless to have "security" when you have no risk of being attacked ! We're in a market niche, remember.

Every time you miss or evade the point... you ask "how?" i answer how, and you object with a "why?" You ask "why?" i answer why, and you object with a "how" and round and round we go...

Talk of memory protection is irrelevant to my example about the Mr Beanbag website being hacked. That was hacked because we left the visitor comments section wide open because we didn't think anyone would have any motivation to hack it, so we didn't bother doing it "properly". We were wrong. Exactly HOW they did it is really not important. You asked WHY someone would hack such-and-such.

We're in a market niche, right. The whole point of this thread is about why we can't have an "amiga-like" system anymore, and the answer is that, insofar as you define "amiga-like" as having no security model whatsoever, no-one in their right mind would produce a new system like that.

Originally Posted by meynaf

The compiler is responsible only of a small part in fact ; it turns 20kb programs into 80kb programs maybe, but it won't turn 20kb into several Mb.
Bloatwares are so by bad programming design, it's not the fault of the compiler. Look at the sources that can be found online. Often i can rewrite them in asm with a lot less lines

Flat wrong.

I have written programs in C++ that do barely anything and the executable comes out in the 100s of kb. And let's look at the way Windows programs come bundled... the usual way is you bundle install all the DLLs the program needs along with the program, because the alternative is "DLL Hell". I know, it completely negates the entire point of a shared library, but nevertheless it is the norm on Windows, because it has no way to manage dependencies. Linux is better on this front.

And i have worked on commercial projects in C++ (do i have to keep repeating myself?) that are full of the sort of bugs that could compromise an unprotected system (segmentation faults to you and me), granted i do generally remove more code than i add but the number of lines of code is really not the problem, it is the interdependency between the various parts, and especially because we just don't know exactly what the user will do until we actually give it to them to use. Some of the bug reports that come back are incredible, "i did X and it crashed," and i'm sitting there with my head in my hands going "why... why did you do that?" Of course it still shouldn't crash in any case, but we can only test cases that we can anticipate.

[meynaf]

Originally Posted by Mrs Beanbag

also do you know what is the "finger exploit" mentioned here? http://eab.abime.net/showthread.php?t=18952

Yup, Op's miami stopped the attack. I remember having seen several ping flood warnings as well on mine. So you can't say we have "no security".
To the risk of repeating myself, closing unneeded tcp ports does a lot more for security than memory protection.

[meynaf]

Originally Posted by Mrs Beanbag

Every time you miss or evade the point... you ask "how?" i answer how, and you object with a "why?" You ask "why?" i answer why, and you object with a "how" and round and round we go...

I always reply to any point made. You don't.
You answer how, then i ask why. That's not necessarily an objection to the "how". And vice versa.
Do you have a concrete example where i miss or evade the point ? Please be SPECIFIC.

Originally Posted by Mrs Beanbag

Talk of memory protection is irrelevant to my example about the Mr Beanbag website being hacked. That was hacked because we left the visitor comments section wide open because we didn't think anyone would have any motivation to hack it, so we didn't bother doing it "properly". We were wrong. Exactly HOW they did it is really not important. You asked WHY someone would hack such-and-such.

The point where you can get hacked without expecting it is agreed long ago, ok ? Now we can reuse the example for something else, ok ?

This only proves that the security of your site must be assured by you, not by your operating system.

Originally Posted by Mrs Beanbag

We're in a market niche, right. The whole point of this thread is about why we can't have an "amiga-like" system anymore, and the answer is that, insofar as you define "amiga-like" as having no security model, no-one in their right mind would produce a new system like that.

Again, you can't say we have no security model. The online security is more or less integrated into the tcp stack (yeah we can have a firewall in case you didn't notice).

I'm not saying we should have no security at all. I'm saying that memory protection should be an OPTION we can switch on and off.

[Mrs Beanbag]

Originally Posted by meynaf

This only proves that the security of your site must be assured by you, not by your operating system.

argh you are DOING IT AGAIN

Yes I know my site should be assured by me! That is BESIDE THE POINT!

YOU asked THIS:

Originally Posted by meynaf

Why the heck would they want to do that is beyond me, btw.

What it proves, is that you should never assume that just because you can't see the point in hacking something, doesn't mean it won't happen. That is the point, that is relevant to what you said. All the stuff about the server having memory protection is completely irrelevant, as is any talk about whose responsibility the security is.

[meynaf]

Originally Posted by Mrs Beanbag

Flat wrong.

I have written programs in C++ that do barely anything and the executable comes out in the 100s of kb. And let's look at the way Windows programs come bundled... the usual way is you bundle install all the DLLs the program needs along with the program, because the alternative is "DLL Hell". I know, it completely negates the entire point of a shared library, but nevertheless it is the norm on Windows, because it has no way to manage dependencies. Linux is better on this front.

Sorry, but i have written programs in C++ as well and if your "hello world" is 100s of kb then you're doing something wrong.
Perhaps you shouldn't include heaps of .lib in your project.

Originally Posted by Mrs Beanbag

And i have worked on commercial projects in C++ (do i have to keep repeating myself?) that are full of the sort of bugs that could compromise an unprotected system (segmentation faults to you and me), granted i do generally remove more code than i add but the number of lines of code is really not the problem, it is the interdependency between the various parts, and especially because we just don't know exactly what the user will do until we actually give it to them to use. Some of the bug reports that come back are incredible, "i did X and it crashed," and i'm sitting there with my head in my hands going "why... why did you do that?" Of course it still shouldn't crash in any case, but we can only test cases that we can anticipate.

You know, design issues are more deadly than bare implementation. This, and not the compiler, leads to bloatware.

If you do new, then init, then function 1, then function 2, then function 3, then delete, instead of doing the whole job with a single call, you get larger code that's all.

I have disassembled megabytes of code, read megabytes of C/C++ sources as well, and very often i am stumped how things can be made complicated for stuff i'd have done with just a few lines...

[meynaf]

Originally Posted by Mrs Beanbag

argh you are DOING IT AGAIN

Yes I know my site should be assured by me! That is BESIDE THE POINT!

What it proves, is that you should never assume that just because you can't see the point in hacking something, doesn't mean it won't happen. That is the point, that is relevant to what you said. All the stuff about the server having memory protection is completely irrelevant, as is any talk about whose responsibility the security is.

If you don't want me to develop on your example, just say it.
It said a lot more than just the point you wanted to make.

[Mrs Beanbag]

Originally Posted by meynaf

Sorry, but i have written programs in C++ as well and if your "hello world" is 100s of kb then you're doing something wrong.
Perhaps you shouldn't include heaps of .lib in your project.

well, it wasn't just Hello World, it did use RTTI and templates, and i did need to include some libs, but i was still astonished at how big it came out.

You know, design issues are more deadly than bare implementation. This, and not the compiler, leads to bloatware.

If you do new, then init, then function 1, then function 2, then function 3, then delete, instead of doing the whole job with a single call, you get larger code that's all.

I have disassembled megabytes of code, read megabytes of C/C++ sources as well, and very often i am stumped how things can be made complicated for stuff i'd have done with just a few lines...

i do know what you mean... i have seen some shockingly over-egged code, and fixed it, but again this is besides the point.

This kind of bad code isn't what gets you bad pointers. It is usually silly mistakes that get you bad pointers.

Oh i have seen unit tests fail on Windows but not Linux (or was it the other way around?) because of a line like the following:

char* myString = 0

Then someone passes myString as an argument to something... well i think you can guess the rest. Maybe you can also guess that this code was written by someone whose first language was Java.

It seems like spotting this sort of thing is a rare talent, somehow. This particular case only happened in the unit test and the program itself seemed fine, so this went unfixed for months until someone gave it me to look at.

Originally Posted by meynaf

If you don't want me to develop on your example, just say it.
It said a lot more than just the point you wanted to make.

You are in full on attack mode now, aren't you?

It is a very simple website. Its simplicity did not protect it. Yeah that example can be made to prove all sorts of things that are beside the point.

[meynaf]

Originally Posted by Mrs Beanbag

i do know what you mean... i have seen some shockingly over-egged code, and fixed it, but again this is besides the point.

This kind of bad code isn't what gets you bad pointers. It is usually silly mistakes that get you bad pointers.

Ok, but the more code you have, the more silly mistakes can creep in.

Originally Posted by Mrs Beanbag

Oh i have seen unit tests fail on Windows but not Linux (or was it the other way around?) because of a line like the following:

char* myString = 0

Then someone passes myString as an argument to something... well i think you can guess the rest. Maybe you can also guess that this code was written by someone whose first language was Java.

It seems like spotting this sort of thing is a rare talent, somehow. This particular case only happened in the unit test and the program itself seemed fine, so this went unfixed for months until someone gave it me to look at.

It's reasons like that which make me like asm.

Originally Posted by Mrs Beanbag

You are in full on attack mode now, aren't you?

No, why ?

Originally Posted by Mrs Beanbag

It is a very simple website. Its simplicity did not protect it. Yeah that example can be made to prove all sorts of things that are beside the point.

Then let's just return to the point.
And mine is that memory protection is optional.

[Mrs Beanbag]

Originally Posted by meynaf

Ok, but the more code you have, the more silly mistakes can creep in.

This is, of course, true, but more code doesn't necessarily mean bloat. There are legitimate reasons for a large code base, and many other reasons for bloat besides a large code base.

Also, the more developers you have.

Then let's just return to the point.
And mine is that memory protection is optional.

Ok. Mine is that memory protection is a very good idea and i see no legitimate reason to turn it off, ever.

Maybe there is a case for games to be able to gain complete control over the screen and the audio hardware. But we could discuss that. I see no reason to go over the operating system's head to do file operations or reserve memory.

Let's imagine a scenario.

Supposing someone were to download a popular multi-player game. They want to play the game because it is a really good game, and all their friends are playing it online. Of course, it has network access. But it turns out the game has a bug which is exploitable in some way that nobody imagined at the time of writing, but it allows someone to hack their own copy of the game in order to send malicious code to other players. You did not write this game, in asm or otherwise.

There is no memory protection. What can this malicious code do, and what can't it do, and why?

[meynaf]

Originally Posted by Mrs Beanbag

Ok. Mine is that memory protection is a very good idea and i see no legitimate reason to turn it off, ever.

Then leave it on, no problem. You can. The fact I myself have it turned off shouldn't be a problem for you at all.

Originally Posted by Mrs Beanbag

Maybe there is a case for games to be able to gain complete control over the screen and the audio hardware. But we could discuss that. I see no reason to go over the operating system's head to do file operations or reserve memory.

Let's say you're writing some low-level data recovery software, and the operating system doesn't provide any relevant API for that purpose. You're then quite happy that you can circumvent this by short-circuiting the OS.

In addition, the fact AmigaOS is so open for hacking, is one big reason why it has survived for so long. For any other system, when support is over, then you're dead.

Originally Posted by Mrs Beanbag

Let's imagine a scenario.

Supposing someone were to download a popular multi-player game. They want to play the game because it is a really good game, and all their friends are playing it online. Of course, it has network access. But it turns out the game has a bug which is exploitable in some way that nobody imagined at the time of writing, but it allows someone to hack their own copy of the game in order to send malicious code to other players. You did not write this game, in asm or otherwise.

There is no memory protection. What can this malicious code do, and what can't it do, and why?

This malicious code can do anything... just like if there were memory protection. At least in an unprotected system i can run my low-level debugger and have a check on the malicious code, try altering the exe in memory to perform tests, and so on. There is no program in which i cannot enter.

[Mrs Beanbag]

Originally Posted by meynaf

This malicious code can do anything... just like if there were memory protection.

This is the part that i really don't understand.

If there is memory protection, malicious code cannot do anything. That is the point of memory protection. You can't just read, write or execute anywhere. You can't directly access hardware resources. There might, in principle, be other holes in the OS security model that let things through... but ideally there would not be, which is what we would strive towards.

Otherwise, if malicious code can do anything, then so can your own code, in which case what are you complaining about?

[meynaf]

Originally Posted by Mrs Beanbag

This is the part that i really don't understand.

If there is memory protection, malicious code cannot do anything. That is the point of memory protection. You can't just read, write or execute anywhere. You can't directly access hardware resources. There might, in principle, be other holes in the OS security model that let things through... but ideally there would not be, which is what we would strive towards.

Otherwise, if malicious code can do anything, then so can your own code, in which case what are you complaining about?

The point is that, even though code can do less things under memory protection, what it can do is largely enough to mess up things a lot and get enough control to turn your machine into a spam-sending zombie - and at the end, there is no difference (apart the reduced freedom under the protected system).

You seem to want an "ideal" system in which there are no security holes. In that case, indeed it would be worth the trouble. But i'm afraid that this simply can't exist.

Anyway, what do you have against a system where memory protection is an option ? Why the heck can't we be true supervisors of our own machines ?

[Mrs Beanbag]

Originally Posted by meynaf

The point is that, even though code can do less things under memory protection, what it can do is largely enough to mess up things a lot and get enough control to turn your machine into a spam-sending zombie - and at the end, there is no difference (apart the reduced freedom under the protected system).

How does it do that? It has to exploit holes in the operating system's security model, surely. You can't force your way through the hardware.

You put a lot of emphasis on spam-factories though, this is not the only reason to hack someone's machine.

You seem to want an "ideal" system in which there are no security holes. In that case, indeed it would be worth the trouble. But i'm afraid that this simply can't exist.

Well there are no (known) holes in the XBox 360 security model. There was one bug in the code when it was first released, which they fixed. Now the only way to hack this machine is to modify the hardware. It's doable... but obviously not remotely.

Anyway, what do you have against a system where memory protection is an option ? Why the heck can't we be true supervisors of our own machines ?

Well, consider your idea of being able to turn it off. If a user process can turn it off, anyone can turn it off. How can you allow the user to turn off protection, without letting malicious code do so? This, of course, is the general crux of the security problem.

You could, perhaps, implement a model like the XBox 360 uses, where only signed code can use kernel space, and where the user can sign their own code (but don't keep the private key on the same machine!)

A possible alternative to hardware memory protection is something like the Java model, run everything in a sort of virtual machine. I'm personally sceptical of claims that Java can outperform C code but that is what some people say. Apparently there are Java exploits too, though.

Ultimately, if you are writing a general purpose OS i think the best you can do is try to stay as far ahead of the hackers as you can.

[vxm]

Originally Posted by meynaf

the fact AmigaOS is so open for hacking, is one big reason why it has survived for so long.

Excellent! Royalty free?

[meynaf]

Originally Posted by Mrs Beanbag

How does it do that? It has to exploit holes in the operating system's security model, surely. You can't force your way through the hardware.

How does it do that ? Well, do you remember the last time you got some malware ? Perhaps you can study it to find out.

Originally Posted by Mrs Beanbag

You put a lot of emphasis on spam-factories though, this is not the only reason to hack someone's machine.

Not the only reason, but a very common one.

Originally Posted by Mrs Beanbag

Well there are no (known) holes in the XBox 360 security model. There was one bug in the code when it was first released, which they fixed. Now the only way to hack this machine is to modify the hardware. It's doable... but obviously not remotely.

No known hole doesn't mean no hole at all.

Originally Posted by Mrs Beanbag

Well, consider your idea of being able to turn it off. If a user process can turn it off, anyone can turn it off. How can you allow the user to turn off protection, without letting malicious code do so? This, of course, is the general crux of the security problem.

If the user can format his hard drive, then malicious code also can ?
If not, why turning memory protection off would be allowed for malicious code for the sole reason the user is allowed to do so ?

Originally Posted by Mrs Beanbag

You could, perhaps, implement a model like the XBox 360 uses, where only signed code can use kernel space, and where the user can sign their own code (but don't keep the private key on the same machine!)

What would prevent hackers from signing their code too ?

Originally Posted by Mrs Beanbag

A possible alternative to hardware memory protection is something like the Java model, run everything in a sort of virtual machine. I'm personally sceptical of claims that Java can outperform C code but that is what some people say. Apparently there are Java exploits too, though.

Sandboxes are secure but not 100%. Especially not Java (which is indeed one of the slowest language i've seen so far).

Originally Posted by Mrs Beanbag

Ultimately, if you are writing a general purpose OS i think the best you can do is try to stay as far ahead of the hackers as you can.

I do not fear hackers.
I'm a lot more concerned about the hardware.


Having a system that can work without memory protection means that it can work without an MMU, which, you have to admit, is :
1. Absolutely mandatory for memory protection,
2. Quite costly to implement in a soft core, which seems the only option we have now.
Killing that ability for "security" doesn't sound clever to me.

[meynaf]

Originally Posted by vxm

Excellent! Royalty free?

You can apply any patch you want to your old 1992 machine royalty free, you know. This is why it's still usable today.