This is super cool, though I very much doubt the following statement:
> AsmBB is very secure web application, because of the internal design and the reduced dependencies.
There's a lot of value in using well tested dependencies, and even Chuck Norris will have bugs writing complex software in assembly. Especially when doing string manipulation which this project should be doing a lot of.
This comment was the first thing that popped up in my head when I saw the title of this post. I remember thinking the exact same when this project was part of a CTF I played, which just hosted the latest version of this project. At least 8 vulnerabilities were found during the competition.
I was rubbed the wrong way with that line too, such claims usually set off red flags, but the OP appears to not write English natively so they might have legitimately missed out some tempering.
e.g. "AsmBB focuses on security in its design and reduced reliance on dependencies."
When Chuck Norris writes complex software in assembly, bugs apologize to Chuck for letting themselves getting carried away, fix their erratic behavior, and promise to never let that happen again.
i agree that assembly is more bug-prone than other languages, but things like internal design and dependencies make a bigger difference. if all your strings are managed with your custom library for dynamically allocated strings, you probably aren't going to have any string buffer overflows because there are only like three places where you could get it wrong. on the other hand, if you're bringing in megabytes of libc code full of string handling, there's lots of potential for bugs
in this case, though, they're linking with sqlite, so all that is out the window
as 10000truths points out in https://news.ycombinator.com/item?id=38985198, in assembly you don't have to deal with undefined behavior, and that helps a lot. occasionally you have behavior that varies by implementations, but there's no nasal demons, and in particular you can add two unknown integers without even hitting implementation-defined behavior. and, in theory, you can never guarantee that a c program won't overflow its stack, and i've had this happen in practice on arduino, where it collided with the heap. and signedness bugs (which are commonly security holes; even qmail had one) are plausibly easier to avoid in assembly than in c, though recent compiler versions help with that
Most popular dependencies aren't well tested because of the constant scope creep. And if they didn't constantly scope creep people would talk about it being "dead" because the last commit was 1+ year ago.
I like this, and kudos for going for assembly language. It is certainly true that reducing dependencies reduces the attack surface for something, that does not, in and of itself, make it "secure". But yes, in a probabilistic sort of way it reduces the chances of exploits. Of course assembly language has zero memory safety or other guarantees which probabilistically increases risk. I can't say if I think they balance out one way or the other. Still, I love me some assembly language applications. For extra credit transpile it to aarch64 and then you can run it on a Pi-Zero (or Pi-W) in a wall wart :-).
I have been researching, off and on, distributed forums. As forums like the one created here became the "go to" after Usenet fell out of favor I have thought a replacement would have both the distribution/replication features of Usenet and the user experience of phpBB (the grandparent of most forum software).
Making it distributed, and eventually consistent, is an excellent distributed systems challenge. So it is kind of like relaxing to a puzzle. If you, gentle reader, have written something along those lines I'd love to have a look.
> Of course assembly language has zero memory safety or other guarantees which probabilistically increases risk. I can't say if I think they balance out one way or the other.
I would posit that assembly + Linux kernel ABI is safer than the traditional C/C++ stack because they are not littered with nearly as much "undefined behavior". Signed arithmetic overflows and underflows as expected. Memory allocation with mmap + MAP_ANONYMOUS initializes it to 0 as expected. Accessing unmapped memory in your address space (including address 0) triggers a SIGSEGV as expected. Your assembler makes much fewer assumptions than your C compiler and doesn't try to be half as clever, so it's more likely to crash and burn on error instead of silently subverting your expectations.
Processing time is insanely fast according to the footer. But the time it takes to transfer the document to Denmark is 500 - 1000ms. Seems like a CDN is better than performant code in this case... Still an impressive feat.
Coming from leading response time initiatives at a Big Tech, ouch. 1s is painful. Obviously transit time is a big part of that but if that's considered "good", well oof.
C is generally first compiled into assembly anyways.
When you program in assembly you're basically just doing the job of the compiler, and can call all the same library functions C code can. You just have to follow the calling conventions of the architecture. It's cumbersome and tedious, but nowhere near impossible.
x64 made calling functions more annoying by using registers then spilling over into the stack after exhausting those. x32 was more pleasant by far, since it only used the stack. x64's convention produces faster code though, by keeping stuff in registers.
RAM is a factor too. I’ve written some programs for Arduino in C that would be a good match for assembly because the stack and C calling conventions are a complete waste. (e.g. sometimes you have no recursive functions). The thing is portability —- as much as I love AVR-8 if my requirements grow AVR-8 has no nowhere to go except maybe an FPGA soft core. In C I can switch to an ARM microcontroller which I find really uninspiring but just performs better.
That’s the one trouble w/ AsmBB that it is specific to some particular architecture.
Using WAL mode with PRAGMA synchronous set to NORMAL, or even in that case? (I'm the furthest from a SQLite expert, just looking at it myself for a project.)
It seems that AsmBB has absolutely no Emoji processing in its asm code, so it's more or less pass-through. Realtime chat does have emoji highlighting in its JS code (a part of the template) though:
function formatEmoji(text) {
var emojiRegEx = /(\u00a9|\u00ae|[\u2000-\u3300]|\ud83c[\ud000-\udfff]|\ud83d[\ud000-\udfff]|\ud83e[\ud000-\udfff])/g;
return text.replace(emojiRegEx, '<span class="emoji"><span>$1</span></span>');
}
This probably meant to catch U+00A9, U+00AE, U+2000..3300 and U+1F000..1FBFF, which is by itself too broad, but also the regex itself is not a faithful translation. (If anyone is wondering the correct solution, just use emoji-regex [1] or more recent `/\p{RGI_Emoji}/v` pattern [2].)
Just spit balling here: some sites like Twitter have their own emoji sets and I wonder if they're saying that they don't do that and instead rely on the OS's normal rendering of emojis.
Really cool concept and execution. I did notice that the live notifications quickly become overwhelming, so there should be some kind of rate limiter on them.
I could see "@User123 has entered the thread" working in the smaller forums I was a part of where I knew everyone. phpBB/vBulletin show a "Users reading this thread: ..." list for that reason, and there were popular plugins for things like "@Foo and @Bar are writing responses to this thread". It helped make the place feel more alive, especially when you were in an intense discussion. It was nice to know the fker was working on his next big quote-by-quote debunk of your post.
But getting a notification when unregistered guests click into a thread doesn't seem useful to anyone.
You could do something similar in C and forgo the standard library. No dependencies other than syscalls. I don't really see a compelling reason to do it in assembly other than as an intellectual exercise.
[+] [-] tasn|2 years ago|reply
> AsmBB is very secure web application, because of the internal design and the reduced dependencies.
There's a lot of value in using well tested dependencies, and even Chuck Norris will have bugs writing complex software in assembly. Especially when doing string manipulation which this project should be doing a lot of.
[+] [-] layer8|2 years ago|reply
Surely you mean CPUs will have bugs executing Chuck Norris' impeccable assembly code.
[+] [-] donran|2 years ago|reply
https://ctftime.org/task/24399
[+] [-] hasmanean|2 years ago|reply
He deal with security threats at the source, by tracking down the hacker and kicking them in the head.
[+] [-] abestic9|2 years ago|reply
e.g. "AsmBB focuses on security in its design and reduced reliance on dependencies."
[+] [-] stefanos82|2 years ago|reply
[+] [-] mgaunard|2 years ago|reply
[+] [-] kragen|2 years ago|reply
in this case, though, they're linking with sqlite, so all that is out the window
as far as i know, though it's a lot simpler than asmbb, httpdito doesn't have any security holes: http://canonical.org/~kragen/sw/dev3/server.s http://canonical.org/~kragen/sw/dev3/httpdito-readme
as 10000truths points out in https://news.ycombinator.com/item?id=38985198, in assembly you don't have to deal with undefined behavior, and that helps a lot. occasionally you have behavior that varies by implementations, but there's no nasal demons, and in particular you can add two unknown integers without even hitting implementation-defined behavior. and, in theory, you can never guarantee that a c program won't overflow its stack, and i've had this happen in practice on arduino, where it collided with the heap. and signedness bugs (which are commonly security holes; even qmail had one) are plausibly easier to avoid in assembly than in c, though recent compiler versions help with that
[+] [-] revskill|2 years ago|reply
[+] [-] bcrosby95|2 years ago|reply
[+] [-] ChuckMcM|2 years ago|reply
I have been researching, off and on, distributed forums. As forums like the one created here became the "go to" after Usenet fell out of favor I have thought a replacement would have both the distribution/replication features of Usenet and the user experience of phpBB (the grandparent of most forum software).
Making it distributed, and eventually consistent, is an excellent distributed systems challenge. So it is kind of like relaxing to a puzzle. If you, gentle reader, have written something along those lines I'd love to have a look.
[+] [-] 10000truths|2 years ago|reply
I would posit that assembly + Linux kernel ABI is safer than the traditional C/C++ stack because they are not littered with nearly as much "undefined behavior". Signed arithmetic overflows and underflows as expected. Memory allocation with mmap + MAP_ANONYMOUS initializes it to 0 as expected. Accessing unmapped memory in your address space (including address 0) triggers a SIGSEGV as expected. Your assembler makes much fewer assumptions than your C compiler and doesn't try to be half as clever, so it's more likely to crash and burn on error instead of silently subverting your expectations.
[+] [-] jansommer|2 years ago|reply
[+] [-] Morthor|2 years ago|reply
[+] [-] Karrot_Kream|2 years ago|reply
[+] [-] andoando|2 years ago|reply
In theory I understand it but the monumental amount of effort it would take to write such “simple” things would take so much time
[+] [-] atdt|2 years ago|reply
[+] [-] pengaru|2 years ago|reply
When you program in assembly you're basically just doing the job of the compiler, and can call all the same library functions C code can. You just have to follow the calling conventions of the architecture. It's cumbersome and tedious, but nowhere near impossible.
x64 made calling functions more annoying by using registers then spilling over into the stack after exhausting those. x32 was more pleasant by far, since it only used the stack. x64's convention produces faster code though, by keeping stuff in registers.
[+] [-] nneonneo|2 years ago|reply
[+] [-] bdcravens|2 years ago|reply
[+] [-] Cthulhu_|2 years ago|reply
Mind you, I understand it given some of the PHP I've seen. But again, that's not the language per se, but how it's used.
[+] [-] PaulHoule|2 years ago|reply
That’s the one trouble w/ AsmBB that it is specific to some particular architecture.
[+] [-] CharlesW|2 years ago|reply
[+] [-] travisgriggs|2 years ago|reply
I wish it would go into greater detail here. I’m unclear what “really native” implies, as opposed to some sort of “kind of native” way?
[+] [-] lifthrasiir|2 years ago|reply
[1] https://unpkg.com/browse/emoji-regex/index.js
[2] https://caniuse.com/mdn-javascript_builtins_regexp_unicodese...
[+] [-] jjice|2 years ago|reply
[+] [-] true_pk|2 years ago|reply
On a side note, showing a list of forum users to someone who isn’t logged in is probably a bad idea. Is it something configurable?
[+] [-] davidcollantes|2 years ago|reply
[+] [-] tommek4077|2 years ago|reply
[+] [-] DigiEggz|2 years ago|reply
[+] [-] hombre_fatal|2 years ago|reply
But getting a notification when unregistered guests click into a thread doesn't seem useful to anyone.
[+] [-] ezekielmudd|2 years ago|reply
[+] [-] fasterik|2 years ago|reply
[+] [-] snvzz|2 years ago|reply
"x86 asm" and "on linux" are combined not larger than than "assembly language".
[+] [-] giancarlostoro|2 years ago|reply
[+] [-] dtx1|2 years ago|reply
https://forum.dlang.org/
[+] [-] kristianp|2 years ago|reply
[+] [-] kstrauser|2 years ago|reply
[+] [-] xyst|2 years ago|reply
How hard would it be to add ARM support?
[+] [-] Dwedit|2 years ago|reply
[+] [-] Hamuko|2 years ago|reply
[+] [-] CharlesW|2 years ago|reply
[+] [-] zxspectrum1982|2 years ago|reply
https://github.com/jart/cosmopolitan
[+] [-] anta40|2 years ago|reply
[+] [-] ijustlovemath|2 years ago|reply
[+] [-] David_FF|2 years ago|reply
[+] [-] uticus|2 years ago|reply