One of the programming challenges at SPOJ involves writing code in.bf, where input validation is practically infeasible. While there wasn't a chance for arbitrary code, an unexpected value could still disrupt the program. With other esoteric programming languages, input validation would be a luxury, and it's no surprise that something theoretical would come out.
When I followed a few links, I came across a sample exploit [github.io], but I don't see why it's an exploit, nor do I understand what said machine is trying to do. As far as I know, it could just be a bug with the program.
Not to mention that type of machine executes it's input, meaning the user already has full control over the device.
I don't think this is a matter of utility but novelty. They said there is no patch and I wonder if it's a matter of fundamental hardware design. I am not to familiar with the architecture but I have a feeling it's virtually single user, so either the user is effectively already by default a super user or the system has minimal design in terms of user access. In such an environment, the exploit is really just the novelty of finding it. It likely affects no more than hobbists and at best it could be used
Or creating an input subroutine rather than doing input directly. It's not like I was required to use.bf, there was also the choice of Intercal which gets close to implementing that feature.
That's a good question. The answer is likely to revolve around whether or not you can build up reusable primitives that the macro processor can reuse.
For example, if you can write code to print a string to the terminal, then the macroprocessor can use that and you now only have to write once command to print a string. This is similar to what we do with assembly: build primitives and reuse them instead of writing raw assembly every time.
Late April Fools (Score:2)
One of the programming challenges at SPOJ involves writing code in .bf, where input validation is practically infeasible. While there wasn't a chance for arbitrary code, an unexpected value could still disrupt the program. With other esoteric programming languages, input validation would be a luxury, and it's no surprise that something theoretical would come out.
When I followed a few links, I came across a sample exploit [github.io], but I don't see why it's an exploit, nor do I understand what said machine is trying to do. As far as I know, it could just be a bug with the program.
Not to mention that type of machine executes it's input, meaning the user already has full control over the device.
Re: Late April Fools (Score:2)
I don't think this is a matter of utility but novelty. They said there is no patch and I wonder if it's a matter of fundamental hardware design. I am not to familiar with the architecture but I have a feeling it's virtually single user, so either the user is effectively already by default a super user or the system has minimal design in terms of user access. In such an environment, the exploit is really just the novelty of finding it. It likely affects no more than hobbists and at best it could be used
Re: (Score:2)
writing code in .bf, where input validation is practically infeasible.,
You just need a halfway decent macro processor, and the language is fine.
Re: (Score:2)
Or creating an input subroutine rather than doing input directly. It's not like I was required to use .bf, there was also the choice of Intercal which gets close to implementing that feature.
Re: (Score:2)
Re: (Score:2)
That's a good question. The answer is likely to revolve around whether or not you can build up reusable primitives that the macro processor can reuse.
For example, if you can write code to print a string to the terminal, then the macroprocessor can use that and you now only have to write once command to print a string. This is similar to what we do with assembly: build primitives and reuse them instead of writing raw assembly every time.
Re: (Score:2)
I would suggest m4 then :P
Re: (Score:2)
I've seen it done before [zerobugsan...faster.net].
Although I would say that m4 is a halfway decent macro processor ;)