<fbytez>
Of course, I don't know the codebase well, but looking at this, it will read from the socket, building a list of characters, until a space is found or an alarm is signalled after 20 minutes. Ripe for abuse.
<fbytez>
I've been messing around with (char) but it doesn't workout because of buffering.
<fbytez>
Some C:
<fbytez>
int main(void) {
<fbytez>
char buf[4096] = {0};
<fbytez>
<fbytez>
size_t len = 0;
<fbytez>
// storage for the request headers
<fbytez>
for (ssize_t n=0;;) {
<fbytez>
if (0 > (n = read(0, &buf[len], sizeof(buf)-len-1)))
<fbytez>
Handles limits simply with nothing getting in the way. No timeout here, of course.
<aw->
fbytez: hi
<aw->
what's your question?
seninha has quit [Quit: Leaving]
<beneroth>
hey aw-
<beneroth>
fbytez, it can be DOSed, even more so as its a forking server. not exploited though, just DoS
<beneroth>
fbytez, your code is quite naive, there is no really limit on the number of headers in HTTP (ofc in practice too many headers don't make sense)
<beneroth>
and as you echo the buffer back to the sender, it's of course open for HTML injection attack
<beneroth>
(but ok, might be just a test setup where this is fine...)
<aw->
hi beneroth, up late ;)
<beneroth>
yeah
<beneroth>
will go to bed now. some stuff kept me up (not coding)
<beneroth>
have a good afternoon :)
<aw->
OK, thanks!
brettgilio has quit [*.net *.split]
brettgilio has joined #picolisp
rob_w has joined #picolisp
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
<fbytez>
I'm sure tiredness had us both; it was late.
<fbytez>
The actual issues with that bit of C are:
<fbytez>
if (n == -1) {
<fbytez>
}
<fbytez>
err(1, "EOF before end of headers");
<fbytez>
err(1, "read");
<fbytez>
} else if (n == 0) {
<fbytez>
<fbytez>
len += (size_t) n;
<fbytez>
It wasn't testing EOF or accumulating `len`.
<fbytez>
HTML injection wouldn't be an issue in this example as it's text/plain and for the sole purpose of echoing whatever was sent.
<abu[m]>
Good morning fbytez :)
<fbytez>
It's not like the individual headers have been parsed at all.
<fbytez>
Morning, sir!
<fbytez>
As for the number of headers, the limit(s) could of course be adjusted to requirements.
<abu[m]>
What is the purpose of all this exercise?
<aw->
hi abu[m], i asked a similar question earlier
<abu[m]>
Hi aw-! Yes, I saw
<aw->
is fbytez razzy by any chance?
<aw->
this reminds me too much of razzy's trolling messages which never seem to go anywhere or have any purpose other than to annoy us with non-sense.
<abu[m]>
Hmm, I think typical razzy questions are different
<abu[m]>
I did not feel them trolling
<abu[m]>
He did serious stuff in pil
<abu[m]>
(also in PilCon)
<aw->
perhaps, i've been afk for a while ;)
<fbytez>
Non-sense? We've been discussing handling reading data from untrusted sources in picolisp.
<abu[m]>
You think the current 'http' function does not suffice?
<abu[m]>
in regard of untrusted clients?
<fbytez>
Right. It looks to only have a 20 minute time-limit and space character as guards.
<abu[m]>
Guard against what?
<abu[m]>
The 20 minute limit is to abort hanging connections
<fbytez>
Bad data.. DoS.
<abu[m]>
You cannot guard against DDOS here
<fbytez>
In terms of how much data is blindly accepted, you can, as demonstrated.
<fbytez>
I didn't realise I was being so badly understood through this entire thread.
<fbytez>
beneroth, seems to get it.
<abu[m]>
The server allows uploading of media like images and video. How would you limit that?
<abu[m]>
The http headers etc are not the problem at all
<fbytez>
I guess if you're serious, this conversation is indeed nonsense. Nevermind.
<aw->
fbytez: sorry tbh i didnt fully grok what you were talking about, perhaps not nonsense, but not very clear to me.
<abu[m]>
It in not nonsense.
<abu[m]>
You need to teach us what to solve how
<abu[m]>
Limit a https stream to some fixed size?
<abu[m]>
Which size to choose then?
<abu[m]>
I would not care. If a bad client sends a GiB of data, the pil process will be killed by the OS
<abu[m]>
memory quota
<abu[m]>
This is bad, as the whole machine slows down, but no further damage
<abu[m]>
Each client session gets its own Pil process. The other processes do not care.
<abu[m]>
If I'd want to protect my server against that, I would do it in httpGate
<abu[m]>
In fact, 20 years ago or so httpGate tracked IP addresses and blocked too many accesses from the same addres
<abu[m]>
But I removed this "feature"
<abu[m]>
In the same way you could add a size check there
<abu[m]>
look at @src/httpGate.c
<beneroth>
well running an interactive application on the public internet is also a quite different threat model then running one within a company LAN
<abu[m]>
All traffic is routed here, in both directions
<beneroth>
it's always a trade-off against what you chose to defend.
<abu[m]>
Inserting a size check here would be trivial
<beneroth>
abu[m], agreed
<abu[m]>
Yeah, the problem is to define against what to defend
<beneroth>
correct
<abu[m]>
Which data size is considered as too big?
<abu[m]>
Uploading an OSM map to the OSM demo may involve a few GiB
<abu[m]>
I do not want to prohibit this
<beneroth>
you decided not to defend against a DoS (not DDoS) which uses a stuck connection or huge uploads. what are the possible consequences? denial of service of the specific application. does it matter? depends on the application.
<abu[m]>
T
<abu[m]>
So fbytez should first make clear what to do exactly before coding something
<beneroth>
well that is always the biggest problem with programming :)
<abu[m]>
☺
<beneroth>
programming is easy. getting the requirements right is the hard part.
razzy has joined #picolisp
<abu[m]>
So the misunderstanding is perhaps the 20-minute timeout. It is *not* against a DDOS or too many data
<abu[m]>
It is the opposite
<abu[m]>
Sometimes a connection is broken or hangs, so the server process simply waits forever
<abu[m]>
I observed that every few weeks or so
<beneroth>
I think, fbytez would prefer a shorter timeout than 20min. As this could be triggered by a malicious client on purpose.
<abu[m]>
And instead of manually killing such processes, they terminate
<abu[m]>
Yeah, but also in 2 minutes many data might be sent
<beneroth>
fbytez, you must be aware that the default http.l which is part of the picolisp distribution is to be executed behind httpGate (also in the picolisp distribution), a small http proxy in C which handles TLS and makes a picolisp process per session.
<beneroth>
and the picolisp process is than kept running until the session times out (20min)
<beneroth>
so the same client is connecting to the same process.
<abu[m]>
Right, and here would be the place to check
<abu[m]>
or limit something
<abu[m]>
But still, it has to be decided what exactly, and this is a tradeoff
<beneroth>
so a malicious client can get themselves stuck, and therefore create/keep one process stuck on the server. but that itself has no effect on the other processes and other sessions per se.
<razzy>
abu[m]: i forgot how to make vip start on specific line of file.
<abu[m]>
You can pass +num
<razzy>
vip +num file.l?
<beneroth>
a malicious client could upload very huge or infinite data, which would eventually fill up the servers ram and kill the session process, maybe slowing other sessions somewhat. but its a bad DoS as the attacker has no leverage, to do the attack it requires the same resources as the DoS consumes.
<abu[m]>
or just + for last line
<abu[m]>
yes, vip + file.l
<abu[m]>
for last line
<razzy>
beneroth: i would start solving this after growing phase of project, or when somebody abuse it :)
<razzy>
abu[m]: thank you :)
<beneroth>
razzy, correct. though one should be aware of it before it happens :)
<beneroth>
so you already know the possible options in case it happens.
<razzy>
beneroth: keep some trigger to send email with to-do-list|options :]
<beneroth>
^^
<beneroth>
when I write TODO comments in code, I always put a date next to it. so when I stumble upon it later, I can see if its something that actually might be still good idea, or if it was just an idea many years ago which is proven unnecessary
<beneroth>
also funny when you have to do then a change, maybe because some interface changed or whatnot, you can stumble on TODO comments in code with note "hey if you ever need X, here would be the right place to add it" :D
<razzy>
beneroth: I found this kind of comment from people who left the company and died from old age :)
<abu[m]>
☺
<razzy>
company I work for has very old code
<JITn>
beneroth: IIUC ""Type System"" is not meerly glorified /assert/ but mystified /assert/. ""Refinement Type""!?
<abu[m]>
I find code here that is from Feb 1987
<razzy>
It is funny to ask "can we call this programmer?" "no, he died years ago"
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
<razzy>
abu[m]: I found data in live database from 1995 :)
<abu[m]>
I see. OK, here it is not living stuff
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
razzy has quit [Ping timeout: 268 seconds]
razzy has joined #picolisp
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
seninha has quit [Quit: Leaving]
razzy has quit [Quit: leaving]
seninha has joined #picolisp
<beneroth>
I worked on code from early 1980s. still in production. SQL. c-shell.
<beneroth>
and I translated fortran code to C, because newer Oracle version did drop the fortran client library.
<beneroth>
I love how you can from code a feeling who wrote it, a single person, multiple ones together or over time.
<beneroth>
and sometimes you can tell they copied it from that website but didn't understand it and left out the most important line which would actually make it meaningful.
<abu[m]>
Cool
seninha has quit [Quit: Leaving]
seninha has joined #picolisp
rob_w has quit [Read error: Connection reset by peer]