7 ms·

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 de

by tasn 3y ago

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.

stefanos82 3y ago
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.
abestic9 3y ago
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."
mgaunard 3y ago
I disagree; dependencies are more of a liability than anything else.
- tasn 3y ago
  I can see this maybe being true in a high level language (depending on the dependency), though it's definitely not the case with assembly. OpenSSL, for example, was hit with quite a few serious bugs over the years, and I'd still choose using it than my own SSL implementation. Especially in assembly.
  - throwup238 3y ago
    > OpenSSL, for example, was hit with quite a few serious bugs over the years, and I'd still choose using it than my own SSL implementation. Especially in assembly. That's the difference between a programmer and a real engineer: an engineer doesn't need any help from dependencies to make his code totally insecure.
    - bee_rider 3y ago
      Engineers do design, implementation is the job of the technician or machinist or somebody like that. If the engineer’s code ends up shipped to customers, something very strange has happened.
      - hardware2win 3y ago
        In my world architects design, engineers provide feedback and implement stuff First time I hear about technicians writing code.
      - kragen 3y ago
        the source code is the design; it plays the same role that schematics or mechanical drawings play for products made by electronic technicians or machinists. the difference is that compilers take the place of technicians or machinists, and that confuses people, often for political/ideological reasons see jack w. reeves's 'code as design' series, beginning with 'what is software design?' from 01992, for a fuller explanation https://www.developerdotstar.com/mag/articles/reeves_design.html https://www.developerdotstar.com/mag/articles/reeves_design.... https://www.developerdotstar.com/mag/articles/reeves_originalletter.html https://www.developerdotstar.com/mag/articles/reeves_origina... https://www.developerdotstar.com/mag/articles/reeves_13yearslater.html https://www.developerdotstar.com/mag/articles/reeves_13years..., and the discussion on wiki https://wiki.c2.com/?TheSourceCodeIsTheDesign= https://wiki.c2.com/?TheSourceCodeIsTheDesign=
        ozozozd 3y ago
        That was a great read. Amazing how it can still be quoted to explain software design 32 years later.
        kragen 3y ago
        glad you enjoyed it!
      - resonious 3y ago
  - kragen 3y ago
    people who are not familiar with cryptography are often unaware of this, but cryptographic algorithms are among the kinds of code most commonly written in assembly not only are they almost never subject to the kinds of security problems we commonly associate with low-level languages like assembly or c (for example, buffer overflows and heap corruption) they also commonly need to run in constant time to prevent timing side-channel information leaks, and while that is not trivial to achieve in any language, it's more feasible in assembly than in c. also, they are commonly a performance bottleneck, and they commonly need kinds of bit manipulations that c is typically slow at, which rewards assembly implementations openssl in particular contains about 85000 lines of assembly language, mostly embedded in perl files. (it uses perl as a sort of alternative macro assembler)
    - tasn 3y ago
      I'm aware, and this is a good point to bring up about cryptography. I had the protocol code in mind when I was talking about the bugs. I should have used curl as example in retrospect. :)
      - kragen 3y ago
        i agree that probably assembly is an especially bug-prone language to implement things like protocol logic and asn.1 parsing; but high-level programming languages are pretty bad at things like that, too. it still mostly depends on your system design: assembly might be a perfectly fine language in which to implement a bytecode interpreter for a safe asn.1 parser in a non-turing-complete language you can formally verify. assembly's weak points don't matter much for bytecode interpreters incidentally those 85000 lines of assembly are about 12% of the total openssl codebase
- ludjer 3y ago
  Do you really want to implement http, ssl and tls; all by your self, what about security hash algorithms? Re inventing the wheel means you also get to go through all the bugs and s purity issue that these open source libraries went through. This is a type of opinion I would expect some one with no understanding about security saying.
  - lifthrasiir 3y ago
    Assuming you do have enough understanding of secure programming, you can actually forgo most dependencies if you really want. You can ignore most edge cases which have to be implemented if you exactly follow the standard (e.g. HTTP parsing rules), supporting only one ciphersuite that is known to be safe and widely used, and so on. Of course that still doesn't justify the use of assembly.
  - mgaunard 3y ago
    If you're building an application that depends heavily on networking for either its performance or reliability, then yes, you are better off rewriting those components and taking on ownership of hardening them to satisfy your requirements than you are relying on someone else that doesn't know your use case and has no incentive to making it work well making sure it works well for you. HTTP is fairly trivial as well; if you're afraid of little things like that, you'll never deliver best-in-class software.
layer8 3y ago
> even Chuck Norris will have bugs writing complex software in assembly. Surely you mean CPUs will have bugs executing Chuck Norris' impeccable assembly code.
hasmanean 3y ago
Chuck Norris does not use an assembler. He live codes machine language directly into DRAM. He deal with security threats at the source, by tracking down the hacker and kicking them in the head.
- hutzlibu 3y ago
  "He deal with security threats at the source, by tracking down the hacker and kicking them in the head." Not just any kicks, but roundhouse kicks of course.
kragen 3y ago
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 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/server.s http://canonical.org/~kragen/sw/dev3/httpdito-readme http://canonical.org/~kragen/sw/dev3/httpdito-readme as 10000truths points out in https://news.ycombinator.com/item?id=38985198 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 3y ago
Whos' Chuck Norris ?
- apgwoz 3y ago
  That answered my question. Chuck Norris is a martial artist that had an acting career. He got a second wind of fame when he became a meme… Chuck Norris Facts. https://en.wikipedia.org/wiki/Chuck_Norris_facts https://en.wikipedia.org/wiki/Chuck_Norris_facts
  - ustad 3y ago
    "Chuck Norris's Social Security number is the last nine digits of pi."
  - noSyncCloud 3y ago
    More correctly, he's a clown that had a clowning career.
donran 3y ago
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. https://ctftime.org/task/24399 https://ctftime.org/task/24399
bcrosby95 3y ago
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.

by tasn 3y ago

stefanos82 3y ago

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.

abestic9 3y ago

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."

mgaunard 3y ago

I disagree; dependencies are more of a liability than anything else.

tasn 3y ago
I can see this maybe being true in a high level language (depending on the dependency), though it's definitely not the case with assembly. OpenSSL, for example, was hit with quite a few serious bugs over the years, and I'd still choose using it than my own SSL implementation. Especially in assembly.
- throwup238 3y ago
  > OpenSSL, for example, was hit with quite a few serious bugs over the years, and I'd still choose using it than my own SSL implementation. Especially in assembly. That's the difference between a programmer and a real engineer: an engineer doesn't need any help from dependencies to make his code totally insecure.
  - bee_rider 3y ago
    Engineers do design, implementation is the job of the technician or machinist or somebody like that. If the engineer’s code ends up shipped to customers, something very strange has happened.
    - hardware2win 3y ago
      In my world architects design, engineers provide feedback and implement stuff First time I hear about technicians writing code.
    - kragen 3y ago
      the source code is the design; it plays the same role that schematics or mechanical drawings play for products made by electronic technicians or machinists. the difference is that compilers take the place of technicians or machinists, and that confuses people, often for political/ideological reasons see jack w. reeves's 'code as design' series, beginning with 'what is software design?' from 01992, for a fuller explanation https://www.developerdotstar.com/mag/articles/reeves_design.html https://www.developerdotstar.com/mag/articles/reeves_design.... https://www.developerdotstar.com/mag/articles/reeves_originalletter.html https://www.developerdotstar.com/mag/articles/reeves_origina... https://www.developerdotstar.com/mag/articles/reeves_13yearslater.html https://www.developerdotstar.com/mag/articles/reeves_13years..., and the discussion on wiki https://wiki.c2.com/?TheSourceCodeIsTheDesign= https://wiki.c2.com/?TheSourceCodeIsTheDesign=
      - ozozozd 3y ago
        That was a great read. Amazing how it can still be quoted to explain software design 32 years later.
        kragen 3y ago
        glad you enjoyed it!
    - resonious 3y ago
- kragen 3y ago
  people who are not familiar with cryptography are often unaware of this, but cryptographic algorithms are among the kinds of code most commonly written in assembly not only are they almost never subject to the kinds of security problems we commonly associate with low-level languages like assembly or c (for example, buffer overflows and heap corruption) they also commonly need to run in constant time to prevent timing side-channel information leaks, and while that is not trivial to achieve in any language, it's more feasible in assembly than in c. also, they are commonly a performance bottleneck, and they commonly need kinds of bit manipulations that c is typically slow at, which rewards assembly implementations openssl in particular contains about 85000 lines of assembly language, mostly embedded in perl files. (it uses perl as a sort of alternative macro assembler)
  - tasn 3y ago
    I'm aware, and this is a good point to bring up about cryptography. I had the protocol code in mind when I was talking about the bugs. I should have used curl as example in retrospect. :)
    - kragen 3y ago
      i agree that probably assembly is an especially bug-prone language to implement things like protocol logic and asn.1 parsing; but high-level programming languages are pretty bad at things like that, too. it still mostly depends on your system design: assembly might be a perfectly fine language in which to implement a bytecode interpreter for a safe asn.1 parser in a non-turing-complete language you can formally verify. assembly's weak points don't matter much for bytecode interpreters incidentally those 85000 lines of assembly are about 12% of the total openssl codebase
ludjer 3y ago
Do you really want to implement http, ssl and tls; all by your self, what about security hash algorithms? Re inventing the wheel means you also get to go through all the bugs and s purity issue that these open source libraries went through. This is a type of opinion I would expect some one with no understanding about security saying.
- lifthrasiir 3y ago
  Assuming you do have enough understanding of secure programming, you can actually forgo most dependencies if you really want. You can ignore most edge cases which have to be implemented if you exactly follow the standard (e.g. HTTP parsing rules), supporting only one ciphersuite that is known to be safe and widely used, and so on. Of course that still doesn't justify the use of assembly.
- mgaunard 3y ago
  If you're building an application that depends heavily on networking for either its performance or reliability, then yes, you are better off rewriting those components and taking on ownership of hardening them to satisfy your requirements than you are relying on someone else that doesn't know your use case and has no incentive to making it work well making sure it works well for you. HTTP is fairly trivial as well; if you're afraid of little things like that, you'll never deliver best-in-class software.

layer8 3y ago

> even Chuck Norris will have bugs writing complex software in assembly. Surely you mean CPUs will have bugs executing Chuck Norris' impeccable assembly code.

hasmanean 3y ago

Chuck Norris does not use an assembler. He live codes machine language directly into DRAM. He deal with security threats at the source, by tracking down the hacker and kicking them in the head.

hutzlibu 3y ago
"He deal with security threats at the source, by tracking down the hacker and kicking them in the head." Not just any kicks, but roundhouse kicks of course.

kragen 3y ago

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 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/server.s http://canonical.org/~kragen/sw/dev3/httpdito-readme http://canonical.org/~kragen/sw/dev3/httpdito-readme as 10000truths points out in https://news.ycombinator.com/item?id=38985198 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 3y ago

Whos' Chuck Norris ?

apgwoz 3y ago
That answered my question. Chuck Norris is a martial artist that had an acting career. He got a second wind of fame when he became a meme… Chuck Norris Facts. https://en.wikipedia.org/wiki/Chuck_Norris_facts https://en.wikipedia.org/wiki/Chuck_Norris_facts
- ustad 3y ago
  "Chuck Norris's Social Security number is the last nine digits of pi."
- noSyncCloud 3y ago
  More correctly, he's a clown that had a clowning career.

donran 3y ago

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. https://ctftime.org/task/24399 https://ctftime.org/task/24399

bcrosby95 3y ago

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.