| Age | Commit message (Collapse) | Author |
|---|
|
For limiting Banner Grabbing attempts.
|
|
|
|
|
|
* ia/ssh/packet_size0/OTP-12645:
ssh: Reset upgrade instructions to default
ssh: Change version (vsn.mk)
ssh: Option minimal_remote_max_packet_size and test cases
ssh: fix loop bug for zero maximum_packet_size.
ssh: Add ssh_info:print/1 to write onto a file descriptor
ssh: Add {active, false} to ssh listen socket
ssh: Change send_buf implementation from list to queue
ssh: Remove error report
|
|
|
|
|
|
|
|
A channel could be opened with the 'max packet size' set to 0. The behaviour is not defined in the ssh rfc:s, and openssh does not handle that case in some special way besides looping.
The introduced solution just "keep quiet" but removes the eternal loop that caused Erlang to core dump.
|
|
|
|
The ssh acceptor process listens for connections and
spawns a process to handle each new connection that it accepts.
The ownership of the accepted socket will be transfered to the new process
that will handle the incomming messages. Before the ownership is
transfered the socket should be in {active, false} or the acceptor
process may receive data aimed for the connection. As the accept socket
inherits the listen options we set {active, false} there.
|
|
A queue is the behaviour that we want, so this makes the code
easier to understand and more effective.
|
|
The error report was assumed to only happen if our code was wrongly
implemented "internal error". However it would also occur when
bad input was recived from the peer, and could hence cause extensive
logging on DoS attacks.
|
|
|
|
|
|
* dgud/observer/fix-atom-tostr/OTP-12634:
observer: Fix crash in process_window
|
|
Links can be to named processes, convert atom to list
|
|
* anders/diameter/hardening/OTP-12628:
Remove potentially large error reason in call to diameter_lib:log/4
Limit FQDN in DiameterURI to 255 octets
Limit DiameterURI ports to 0-65535 digits on decode
Add service_opt() incoming_maxlen
Add guard to reject {spawn_opt, false} as transport/service_opt()
|
|
* sverk/large-list_to_integer-bug/OTP-12624:
erts: Fix bug in list_to_integer for very large strings
|
|
The function is intended to be traced on, to see abnormalities (mostly)
without producing excessive output. In the case of decode failure, the
error reason can be things like {badmatch, HugeBinary}.
Missed in commit 0058430.
|
|
As for the port number in the parent commit, a FQDN can't be arbitrarily
long, at most 255 octets. Make decode fail if it's more.
|
|
A port number is a 16-bit integer, but the regexp used to parse it in
commit 1590920 slavishly followed the RFC 6733 grammar in matching an
arbitrary number of digits. Make decode fail if it's anything more than
5, to avoid doing erlang:list_to_integer/1 on arbitrarily large lists.
Also make it fail if the resulting integer is outside of the expected
range.
|
|
To bound the length of incoming messages that will be decoded. A message
longer than the specified number of bytes is discarded. An
incoming_maxlen_exceeded counter is incremented to make note of the
occurrence.
The motivation is to prevent a sufficiently malicious peer from
generating significant load by sending long messages with many AVPs for
diameter to decode. The 24-bit message length header accomodates
(16#FFFFFF - 20) div 12 = 1398099
Unsigned32 AVPs for example, which the current record-valued decode is
too slow with in practice. A bound of 16#FFFF bytes allows for 5461
small AVPs, which is probably more than enough for the majority of
applications, but the default is the full 16#FFFFFF.
|
|
|
|
* egil/maint/process_dictionary-initial-size/OTP-12535:
erts: Document option 'hpds'
erts: Enable command line argument for initial pd size
|
|
It was possible to configure the option, but doing so caused the service
to fail when starting a watchdog process:
{function_clause,
[{diameter_service,'-spawn_opts/1-lc$^0/1-0-',
[false],
[{file,"base/diameter_service.erl"},{line,846}]},
{diameter_service,start,5,
[{file,"base/diameter_service.erl"},{line,820}]},
{diameter_service,start,3,
[{file,"base/diameter_service.erl"},{line,782}]},
{diameter_service,handle_call,3,
[{file,"base/diameter_service.erl"},{line,385}]},
{gen_server,try_handle_call,4,[{file,"gen_server.erl"},{line,607}]},
{gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,639}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,237}]}]}
Tests for the option in the config suite were also missing.
Bungled in commit 78b3dc6.
|
|
* peppe/common_test/failing_telnet_tests:
Add documentation and make get_data behaviour backwards compatible
Introduce polling feature in ct_telnet
Fix problem with invalid timeouts because of truncated floats
OTP-12627
|
|
|
|
list_to_integer(lists:duplicate(10000000,$0)).
crashed due to overflow when calculating nr heap words.
|
|
* egil/fix-term-cmp/OTP-12623:
erts: Fix comparison of exact terms
|
|
|
|
Use '+hpds size' to set initial process dictionary size for spawned processes.
|
|
* erland/diameter/time_api_change/OTP-12439:
Update with changes in new time api otp_SUITE: change filter för diameter
|
|
Comparison of exact terms could cause faulty term tests.
This was caused by a faulty (too small) internal type.
Symptom:
-1 = erts_internal:cmp_term(2147483648,0). %% wrong
Correct:
1 = erts_internal:cmp_term(2147483648,0).
Reported-by: Jesper Louis Andersen
|
|
|
|
* anders/diameter/17.5/OTP-12435:
vsn -> 1.9
Update appup for 17.5
Minor doc fix
|
|
|
|
Required load order by ticket.
- OTP-11492, answer messages discarded
- OTP-12415, retransmission failure
- OTP-12475, grouped AVP decode
- OTP-12543, no requests after DPR
none
- OTP-12412, shutdown issues
diameter_lib
diameter_service
- OTP-12428, transport_opt() pool_size
diameter_lib
diameter_service
diameter, diameter_config
diameter_{tcp,sctp}
diameter, diameter_config
- OTP-12439, new time api in Erlang/OTP 18
diameter_lib
diameter_{config,peer,reg,service,session,stats,sync,watchdog,sctp}
- OTP-11952, service_opt() decode_string
- OTP-12589, DiameterURI encode/decode
diameter_{capx,codec,peer}
diameter_types
diameter_traffic
diameter_{service,peer_fsm}
diameter_watchdog
diameter, diameter_config
- OTP-12542, DPR with diameter:call/4
diameter_{peer_fsm,watchdog}
diameter, diameter_config
- OTP-12609, transport_opt() dpr_timeout
diameter_peer_fsm
diameter, diameter_config
|
|
|
|
* anders/diameter/dpr/OTP-12609:
Discard incoming/outgoing requests after incoming DPR
Add transport_opt() dpr_timeout
Be lenient with errors in incoming DPR
|
|
* anders/diameter/DiameterURI/OTP-12589:
Adapt to changed DiameterURI defaults in RFC 6733
Reject transport=udp;protocol=diameter at DiameterURI encode
|
|
Despite claims of full backwards compatibility, the text of RFC 6733
changes the interpretation of unspecified values in a DiameterURI. In
particular, 3588 says that the default port and transport are 3868 and
sctp respectively, while 6733 says it's either 3868/tcp (aaa) or
5658/tcp (aaas). The 3588 defaults were used regardless, but now use
them only if the common dictionary is diameter_gen_base_rfc3588. The
6733 defaults are used otherwise.
This kind of change in the standard can lead to interop problems, since
a node has to know which RFC its peer is following to know that it will
properly interpret missing URI components. Encode of a URI includes all
components to avoid such confusion.
That said, note that the defaults in the diameter_uri record have *not*
been changed. This avoids breaking code that depends on them, but the
risk is that such code sends inappropriate values. The record defaults
may be changed in a future release, to force values to be explicitly
specified.
|
|
Both RFC 3588 and 6733 disallow the combination. Make its encode fail.
|
|
* anders/diameter/string_decode/OTP-11952:
Let examples override default service options
Set {restrict_connections, false} in example server
Set {string_decode, false} in examples
Test {string_decode, false} in traffic suite
Add service_opt() string_decode
Strip potentially large terms when sending outgoing Diameter messages
Improve language consistency in diameter(1)
|
|
* anders/diameter/route_record/OTP-12551:
Fix ordering of AVPs in relayed messages
|
|
To make them a bit more flexible. Can now do things like this:
server:start([{'Product-Name', "Bob"}]),
server:listen({tcp, [{capx_timeout, 2000}]})
Beware that the latter is completely different from this:
server:listen(tcp, [{capx_timeout, 2000}])
|
|
Since there's no reason to reject a client that wants to establish
multiple connections, given that diameter can handle it.
|
|
So as to do what's now recommended in diameter(1), in the grandparent
commit.
|
|
By adding string decode or not in the server or client as another
combination. Run all traffic cases in parallel: remove the sequential
tests. Common test seems unable to deal with {group, X, [parallel]}
within a group.
|
|
To control whether stringish Diameter types are decoded to string or
left as binary. The motivation is the same as in the parent commit: to
avoid large strings being copied when incoming Diameter messages are
passed between processes; or *if* in the case of messages destined for
handle_request and handle_answer callbacks, since these are decoded in
the dedicated processes that the callbacks take place in. It would be
possible to do something about other messages without requiring an
option, but disabling the decode is the most effective.
The value is a boolean(), true being the default for backwards
compatibility. Setting false causes both diameter_caps records and
decoded messages to contain binary() in relevant places that previously
had string(): diameter_app(3) callbacks need to be prepared for the
change.
The Diameter types affected are OctetString and the derived types that
can contain arbitrarily large values: OctetString, UTF8String,
DiameterIdentity, DiameterURI, IPFilterRule, and QoSFilterRule. Time and
Address are unaffected.
The DiameterURI decode has been redone using re(3), which both
simplifies and does away with a vulnerability resulting from the
conversion of arbitrary strings to atom.
The solution continues the use and abuse of the process dictionary for
encode/decode purposes, last seen in commit 0f9cdba.
|
|
|
